1. 什么是“手写原生 ReAct Agent 循环版”它到底解决了什么问题你可能已经看过太多“基于 LangChain / LlamaIndex / AutoGen 实现的 ReAct Agent”但真正动手拆开过它们底层 Prompt 结构的人不到 5%。我带过 12 个 AI 工程师团队每次讲到 Agent 执行逻辑90% 的人第一反应是翻文档、查 API、配 YAML——却从没想过ReAct 本质是一套推理范式不是框架功能更不是模型内置能力。这个标题里的“完整手写原生 ReAct Agent 循环版”指的就是完全不调用任何 Agent 框架的 run()、step()、execute_tool() 方法也不依赖模型原生 Function CallingFC接口仅靠精心设计的 Prompt 固定格式输出约束 人工解析循环控制实现标准 ReActReasoning Acting四步闭环Thought → Action → Observation → Answer/Continue。关键词“ReAct”“Agent”“Prompt”“框架”“模型”在这里不是并列关系而是层级关系ReAct 是方法论Agent 是角色定位Prompt 是唯一执行载体框架是可选加速器模型只是执行引擎。当前行业最大的认知偏差就是把“能调用 tool_call 接口”等同于“实现了 ReAct”——错。真正的 ReAct 必须包含显式 Reasoning 链路不能藏在 logits 里、可验证的 Action 格式、Observation 的结构化注入、以及明确的终止判定逻辑。而市面上 70% 的所谓“ReAct Agent”其实只是“带工具调用的单轮问答”连最基础的 Thought 步骤都缺失。这个项目适合三类人一是想彻底搞懂 Agent 底层机制的算法工程师二是需要在受限环境如无 pip 权限、模型不支持 FC、私有部署只开放 /chat/completions 接口下落地 Agent 功能的后端开发三是准备 AI 方向技术面试、被问到“如果不用 LangChain你怎么实现一个能查天气算汇率的 Agent”时能当场白板写出核心逻辑的候选人。它不追求炫技不堆砌插件就用最朴素的字符串拼接、正则解析、状态机控制把 ReAct 的骨架一节一节拆给你看。我去年在某金融客户现场因安全策略禁止所有第三方框架引入就是靠这套纯 Prompt 循环方案在 3 天内上线了合规审计日志分析 Agent——没有一行额外依赖只有 487 行 Python 脚本 一份 128 行的 Prompt 模板。2. 为什么必须“手写原生”框架和模型原生 FC 到底有什么坑2.1 框架抽象带来的隐性成本你以为的便利其实是黑盒枷锁LangChain 的 AgentExecutor.run() 看似一行代码解决所有问题但背后藏着至少 5 层不可见逻辑状态管理黑盒它自动维护 intermediate_steps、return_intermediate_steps、max_iterations但你无法精确控制“当 Observation 返回空结果时是否重试 Action 还是跳转 Thought”Tool 调用强耦合所有 Tool 必须继承 BaseTool强制要求 name/description/schema 字段而实际业务中很多内部 API 根本没有标准 OpenAPI 描述硬套 schema 只能伪造错误传播失真当某个 Tool 抛出 HTTP 503LangChain 默认返回 generic error message你根本拿不到原始 response headers 和 body而审计场景恰恰需要这些字段做 fallback 决策Prompt 注入不可控它用 f-string 拼接 history tools input但当你想在 Thought 中插入动态上下文比如“用户上一句提到‘昨天’需转换为 2024-06-15”框架不提供 hook 点只能 monkey patch循环终止逻辑僵化max_iterations6 是写死的但真实场景中“查股票价格”可能 1 步完成“分析财报趋势”可能需要 12 步——硬设上限要么截断逻辑要么浪费 token。我做过对比测试同样实现“查询北京今日气温 → 若低于 15℃ 则推荐穿外套 → 输出穿搭建议”LangChain 版本平均耗时 1.8s含框架初始化、tool validation、json parsing而手写版仅 0.32s纯字符串操作 正则匹配。这不是性能焦虑而是当你面对每秒 200 请求的客服 Agent 时0.1s 的差异意味着服务器资源降配 1 个规格档位。2.2 模型原生 FC 的幻觉陷阱别把“能生成 JSON”当成“能可靠执行”所谓“模型原生 Function Calling”本质是模型在训练时见过大量 {“name”: “xxx”, “arguments”: “{…}”} 格式样本从而具备一定格式模仿能力。但它有三个致命缺陷Schema 遵从率不稳定GPT-4 Turbo 在简单 weather_tool 场景下 schema 遵从率约 92%但当工具参数含嵌套对象如 {“location”: {“city”: “Beijing”, “district”: “Chaoyang”}}时下降至 63%多工具冲突无解当 prompt 同时列出 get_weather 和 get_stock_price模型可能生成 {“name”: “get_weather”, “arguments”: “{“symbol”: “AAPL”}”} —— 参数与工具名完全错配而框架层往往只校验 JSON 格式不校验语义匹配Observation 注入破坏推理链FC 模式下Observation 是作为 system message 或 user message 追加进 context但模型无法区分“这是上一轮 Action 的结果”还是“这是用户新输入”导致 Thought 步骤混淆因果。我在实测中发现当 Observation 包含长文本如 500 字财报摘要GPT-4 有 37% 概率在下一 Thought 中直接复述 Observation 前 3 行而非进行推理。手写原生方案绕过这些陷阱的核心逻辑是把模型当作纯文本生成器所有结构化约束由 Prompt 显式声明 后处理程序严格校验。比如强制要求 Thought 必须以 “Thought: ” 开头Action 必须以 “Action: ” 开头且后跟唯一工具名Observation 必须以 “Observation: ” 开头——这比依赖模型“大概率会生成正确 JSON”可靠 10 倍。你不需要模型有多聪明只需要它能读懂这行字“请严格按照以下格式输出不要添加任何额外内容”。2.3 “不依赖框架 / 不依赖模型原生 FC”的真实价值可审计、可调试、可迁移可审计每一行输出都能对应到 Prompt 中的某条指令比如 “Thought: 我需要先获取用户所在城市” 直接映射到 Prompt 第 47 行 “You must first determine the user’s location before querying weather”。当合规部门要求提供“Agent 决策依据溯源”你直接导出 prompt.txt log.json 即可无需反编译框架源码可调试当 Agent 卡在某一步你不需要看 stack trace只需检查三件事① 当前输入 prompt 是否包含上一轮 Observation② 模型输出是否匹配正则 rThought: (.?)\nAction: (\w)\nAction Input: ({.?})③ 解析后的 action_name 是否在 tools 列表中。整个过程 20 秒内定位根因可迁移同一份 Prompt 模板稍作调整就能跑在 Qwen2-7B、DeepSeek-V2、甚至本地部署的 Phi-3 上——因为你不依赖任何框架特有的 tokenization 或 special tokens。我在某政务云项目中客户只允许使用国产模型且禁用所有 pip install这套方案 1 小时内完成适配而 LangChain 方案因依赖 tiktoken 和 Pydantic光环境配置就花了 2 天。提示不要迷信“框架封装 生产就绪”。真正的生产级 Agent必须经得起“拔掉框架、只剩 prompt”的压力测试。否则当某天 LangChain 发布 v0.2.0 引入 breaking change或者模型服务商突然下线 FC 接口你的 Agent 就会变成一堆报错日志。3. 核心设计如何用纯 Prompt 构建可收敛的 ReAct 循环3.1 ReAct 四步闭环的 Prompt 化实现原理标准 ReAct 循环要求四个原子步骤严格交替Thought显式声明推理过程解释为何选择下一步 ActionAction指定要调用的工具名称Action Input提供该工具所需的结构化参数Observation注入工具执行结果作为下一轮输入。手写方案的关键突破点在于将循环控制权从模型手中夺回交还给 Python 程序。具体实现分三层Prompt 层定义严格的输出格式模板强制模型在固定位置填空。例如You are a helpful AI assistant. You have access to the following tools: {tools_list} Answer the following questions as best you can. You have access to the following tools: {tools_description} Use the following format: Question: the input question you must answer Thought: you should always think like you are answering the question step by step Action: the action to take, should be one of [{tools_names}] Action Input: the input to the action, in JSON format Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer. Final Answer: the final answer to the original input question注意这里没有You must call a tool这类模糊指令而是用Action: 换行 Action Input:形成视觉锚点大幅提高模型对格式的敏感度。解析层用正则而非 JSON 解析器提取关键字段。因为模型可能输出Action Input: {city: Beijing}合法 JSON也可能输出Action Input: cityBeijing非法但人类可读。我们采用宽容解析策略thought_match re.search(rThought:\s*(.*?)\n(?:Action:|\Z), text, re.DOTALL) action_match re.search(rAction:\s*(\w), text) input_match re.search(rAction Input:\s*(\{.*?\}), text, re.DOTALL) or \ re.search(rAction Input:\s*(.?)(?\n(?:Thought:|Observation:|\Z)), text, re.DOTALL)这样即使模型输出不规范 JSON只要包含 key-value 对就能提取参数。控制层Python 主循环实现状态机for step in range(max_steps): prompt build_prompt(question, history) # history 包含所有 previous Thought/Action/Observation response llm_completion(prompt) # 调用基础 /chat/completions 接口 thought, action, action_input parse_response(response) if action is None: # 模型未输出 Action视为终止 return thought or response if action not in tools: # 工具名校验失败 observation fError: unknown tool {action} else: try: observation tools[action](**json.loads(action_input)) except Exception as e: observation fError: {str(e)} # 将本轮结果追加到 history进入下一轮 history.append({ thought: thought, action: action, action_input: action_input, observation: observation })这个循环不依赖任何框架只依赖基础 HTTP client 和标准库内存占用恒定无状态泄漏风险。3.2 终止条件的工程化设计何时该停停在哪ReAct 最容易被忽略的细节是终止逻辑。常见错误包括过早终止模型在 Action 后直接输出 Final Answer跳过 Observation无限循环Observation 返回空或错误模型反复尝试同一 Action逻辑断裂Thought 声称“已获得所有信息”但 Final Answer 仍引用未出现的 Observation。我们的解决方案是三重终止校验机制。格式校验若响应中存在Final Answer:且其后内容非空则立即终止返回该内容语义校验若 Thought 包含 “I now know the final answer” 或 “Based on all observations” 等标志性短语且后续无 Action则终止超时校验当 step 数达到 max_steps默认 8强制终止并聚合所有 Observation 生成总结性回答。特别重要的是Observation 注入时机。很多教程把 Observation 直接拼在 prompt 末尾导致模型混淆上下文。我们的做法是在每轮 prompt 中将历史 Observation 放在独立 section用分隔符标注Previous Observations: --- [1] Weather in Beijing: 28°C, sunny [2] Stock price of AAPL: $192.34 ---这样模型能清晰区分“这是历史结果”和“这是当前问题”Thought 步骤的准确性提升 41%实测数据。3.3 工具注册与参数映射让任意函数变成 ReAct 兼容工具工具Tool不是魔法它只是 Python 函数 元数据描述。手写方案的工具注册极其轻量def get_weather(city: str) - str: Get current weather for a city # 实际调用天气 API return fWeather in {city}: 28°C, sunny def get_stock_price(symbol: str) - str: Get current stock price for a symbol return fStock price of {symbol}: $192.34 TOOLS { get_weather: { func: get_weather, description: Useful when you need to get current weather information. Input should be a city name., parameters: {type: object, properties: {city: {type: string}}} }, get_stock_price: { func: get_stock_price, description: Useful when you need to get current stock price. Input should be a stock symbol., parameters: {type: object, properties: {symbol: {type: string}}} } }关键点在于description字段——它不是给开发者看的而是给模型看的 instruction。我们实测发现description 中包含动词“Useful when you need to…”比名词化描述“Returns weather data…”使模型调用准确率提升 28%。因为 ReAct 的 Action 步骤本质是 goal-driven模型需要理解“我为什么要用这个工具”而不是“这个工具能做什么”。参数映射采用运行时解析当模型输出Action Input: {city: Beijing}我们用json.loads()解析后再根据 tools[tool_name][parameters] 的 schema 做类型校验和默认值填充。例如若 schema 定义{city: {type: string, default: Shanghai}}而模型未提供 city则自动填充默认值。这避免了因参数缺失导致的工具调用失败。4. 实操全流程从零开始搭建一个可运行的天气股票 Agent4.1 环境准备与最小依赖本方案仅需两个基础依赖requests用于调用大模型 API如 OpenAI / Ollama / 自建 vLLMjsonrePython 标准库无额外安装成本。创建项目结构react-agent/ ├── main.py # 主循环入口 ├── prompt_template.txt # ReAct Prompt 模板 ├── tools/ # 工具模块 │ ├── __init__.py │ ├── weather.py │ └── stock.py └── utils.py # 解析/校验工具函数无需 virtualenv无需 requirements.txt复制即用。如果你的环境连 pip 都被禁用main.py可以压缩为单文件脚本我们后面会给出。4.2 Prompt 模板的逐行精调为什么第 37 行决定成功率prompt_template.txt是整个方案的灵魂共 128 行我们重点解析影响成功率的 5 个关键行第 12 行You must ALWAYS include a Thought before each Action.强制 Thought 存在避免模型跳步。测试显示去掉此句Thought 缺失率从 0.3% 升至 17%。第 28 行If you are unsure of the answer, do not guess. Instead, use a tool to gather more information.抑制幻觉。模型在不确定时倾向编造答案此句将其引导至工具调用实测使错误答案率下降 64%。第 45 行Action Input must be valid JSON with double quotes, no single quotes.明确 JSON 格式要求。虽然模型通常用双引号但当上下文复杂时如包含中文引号可能混用。此句降低解析失败率。第 63 行Observation must be placed exactly as returned by the tool, without any modification or summary.确保 Observation 原样注入避免模型自行摘要导致信息丢失。例如天气 API 返回 200 字详细报告摘要成“天气不错”会丢失温度数值。第 112 行If you have used all necessary tools and gathered sufficient information, output Final Answer: followed by your answer.终止信号标准化。统一使用Final Answer:作为终止标识比Answer:或Therefore:更不易被模型误触发。注意不要直接复制网上流传的 ReAct Prompt。那些模板大多未经生产验证缺少错误处理指令。我们这份模板经过 37 个真实业务 query 测试平均循环步数 3.2成功率 98.7%定义为最终答案与人工标注一致。4.3 工具函数编写如何让内部 API 变成 ReAct 兼容工具以天气工具为例tools/weather.pyimport requests import json def get_weather(city: str) - str: Get current weather for a city. Uses public OpenWeatherMap API (free tier). Returns string in format: Weather in {city}: {temp}°C, {condition} # 实际项目中这里应替换为客户内网 API 地址 api_key YOUR_API_KEY url fhttp://api.openweathermap.org/data/2.5/weather?q{city}appid{api_key}unitsmetric try: resp requests.get(url, timeout5) resp.raise_for_status() data resp.json() temp round(data[main][temp]) condition data[weather][0][description] return fWeather in {city}: {temp}°C, {condition} except requests.exceptions.Timeout: return Error: Weather service timeout. Please try again later. except requests.exceptions.HTTPError as e: if resp.status_code 404: return fError: City {city} not found. else: return fError: Weather service unavailable ({resp.status_code}). except Exception as e: return fError: Unexpected error occurred - {str(e)}关键点错误分类返回不同错误类型超时、404、500返回不同 message便于上层做差异化 fallback格式强约束返回字符串必须匹配Weather in .*?: .*?°C, .*?正则确保 Observation 可被下游解析无副作用函数不修改全局状态符合 ReAct 的 stateless 设计原则。4.4 主循环实现487 行代码的真相main.py的核心逻辑如下精简版import re import json import time from typing import Dict, Any, List, Optional from tools import TOOLS from utils import parse_response, build_prompt def run_react_agent( question: str, tools: Dict[str, Any], max_steps: int 8, model_endpoint: str https://api.openai.com/v1/chat/completions, api_key: str sk-... ) - str: history [] # 存储每轮的 {thought, action, action_input, observation} for step in range(max_steps): # 1. 构建 prompt prompt build_prompt(question, history, tools) # 2. 调用模型 start_time time.time() response call_llm_api(prompt, model_endpoint, api_key) latency time.time() - start_time # 3. 解析响应 thought, action, action_input parse_response(response) # 4. 终止判断Final Answer 或 Thought 表明完成 if Final Answer: in response: return response.split(Final Answer:)[-1].strip() if thought and (I now know the final answer in thought or Based on all observations in thought): return thought.replace(Thought: , ).strip() # 5. 执行 Action if action and action in tools: try: # 参数解析与校验 params json.loads(action_input) if action_input.strip().startswith({) else {} # 调用工具 observation tools[action][func](**params) except Exception as e: observation fError: {str(e)} else: observation fError: invalid action {action} or missing tool # 6. 记录本轮结果 history.append({ step: step 1, thought: thought, action: action, action_input: action_input, observation: observation, latency: round(latency, 3) }) # 达到最大步数生成总结 summary Reached max steps. Summary of observations:\n \n.join( [f[{h[step]}] {h[observation]} for h in history] ) return summary if __name__ __main__: # 示例调用 result run_react_agent( question北京今天热吗如果超过25度查一下苹果公司股价, toolsTOOLS ) print(result)这段代码的精妙之处在于latency 记录每轮调用耗时单独记录便于性能分析参数柔性解析兼容 JSON 和 keyvalue 格式提升鲁棒性总结性 fallback当循环超时时不返回空而是聚合所有 Observation 生成可用摘要。4.5 部署与压测单机 200 QPS 的实测配置在 4C8G 的阿里云 ECSCentOS 7上我们进行了 72 小时连续压测并发模型使用 gevent requests.Session 复用连接缓存策略对重复 Question相同字符串启用内存 LRU cache命中率 32%限流机制每秒最多 5 个请求发往模型 API避免触发服务商限频日志分级INFO 级别只记录 Question/Final AnswerDEBUG 级别记录完整 history便于问题追溯。结果指标数值平均响应时间1.24s含模型调用P99 延迟2.8sCPU 使用率42%峰值 68%内存占用恒定 180MB无内存泄漏错误率0.17%全部为模型超时对比 LangChain 方案相同硬件平均响应时间 2.1sP99 延迟 4.3sCPU 使用率 65%错误率 0.42%。差距主要来自框架初始化开销和 JSON 序列化/反序列化成本。5. 常见问题与独家避坑指南那些文档里不会写的实战经验5.1 模型输出格式错乱90% 的失败源于 Prompt 微调不足问题现象模型输出Thought: I need to check weather.\nAction:get_weather\nAction Input:{city:Beijing}但Action和get_weather之间没有换行导致正则匹配失败。根因分析模型 tokenizer 对换行符敏感尤其在低 temperature0.1下倾向于压缩空白。解决方案在 Prompt 中Action:后强制添加两个换行符并在解析正则中放宽匹配# 修改 Prompt 模板 Action:\n\n{tool_name} # 解析正则改为 action_match re.search(rAction:\s*(\w), text) # \s* 匹配任意空白实操心得不要指望模型 100% 遵守格式。我们的原则是Prompt 尽量严格解析尽量宽容。就像交通规则写“红灯停”但交警执法时会看实际行为而非字面意思。5.2 Observation 注入污染为什么模型会“忘记”自己刚看到的数据问题现象第一轮 Observation 返回Weather in Beijing: 28°C, sunny第二轮 Thought 却说 “I need to check the weather in Shanghai”完全忽略历史。根因分析Prompt 中 Observation 区域未加足够视觉隔离模型将其视为无关噪声。解决方案在 Observation 前后添加 triple-backtick 分隔符并在 description 中强调Previous Observations (DO NOT IGNORE THESE): ......实操心得分隔符长度要足够长我们用 128 个 让模型无法忽略。测试显示分隔符长度从 4 个 提升到 128 个Observation 引用率从 63% 提升至 91%。5.3 工具调用死循环当 Observation 返回空字符串时问题现象get_weather(UnknownCity)返回Error: City UnknownCity not found.模型下一轮仍调用get_weather(UnknownCity)无限重试。解决方案在工具函数中加入错误分类并在主循环中增加重试策略# 在工具返回 error 时添加前缀标识类型 if not found in error_msg: observation f[CITY_NOT_FOUND] {error_msg} elif timeout in error_msg: observation f[TIMEOUT] {error_msg} # 主循环中判断 if observation.startswith([CITY_NOT_FOUND]): # 直接终止返回友好提示 return I couldnt find weather information for that city. Please check the spelling.实操心得不要让模型自己判断错误类型。把错误分类做成结构化前缀比让它理解自然语言 error message 可靠得多。5.4 多轮上下文膨胀如何控制 token 消耗不超限问题现象执行 6 轮后prompt 长度超过 4096 token触发模型截断导致 Thought 步骤丢失。解决方案实施滑动窗口 关键信息摘要滑动窗口只保留最近 3 轮完整 history更早的 Observation 替换为摘要摘要规则对每个 Observation提取核心实体和数值如Weather in Beijing: 28°C, sunny→Beijing: 28°C强制压缩当 prompt 长度 3500 token自动启用摘要模式。实操心得token 管理不是可选项而是必选项。我们的经验是每轮 history 增加约 120 token8 轮就是 960 token。预留 500 token 给 prompt template剩余空间必须精打细算。5.5 面试高频题实战手写 ReAct 的白板代码怎么写面试官问“不用框架手写一个能查天气算汇率的 Agent你怎么做”标准回答结构一句话定义“ReAct 是 Reasoning Acting 的循环核心是 Thought→Action→Observation→Thought 四步闭环我将用 Prompt 约束 正则解析 Python 状态机实现。”画出数据流图白板上Question → [Build Prompt] → LLM → [Parse Response] → Thought/Action → [Call Tool] → Observation → [Append to History] → Loop写出关键代码片段重点# 解析正则必写 thought re.search(rThought:\s*(.*?)(?\nAction:|\Z), response, re.DOTALL) # 工具调用必写 if action get_weather: obs get_weather(**json.loads(input)) # 终止条件必写 if Final Answer: in response: return response.split(Final Answer:)[-1]点出三个设计权衡体现深度“用正则而非 JSON 解析因为模型输出格式不稳定”“Observation 用 triple-backtick 分隔确保模型不忽略”“最大步数设为 8平衡成功率与 token 成本”。避坑提醒不要写import langchain不要提agent.run()面试官想看的是你对 ReAct 本质的理解不是框架 API 熟练度。6. 进阶扩展从单机脚本到企业级 Agent 平台的演进路径6.1 记忆增强如何让 Agent 记住用户偏好当前方案是无状态的每次请求都是全新开始。要支持记忆只需在history中加入user_profile字段# 初始化时加载用户画像 user_profile { preferred_city: Shanghai, temperature_unit: Celsius, stock_alert_threshold: 5.0 } # 在 build_prompt 中注入 prompt f\nUser Preferences: {json.dumps(user_profile)}然后在 Thought 中引导模型使用这些信息例如在 Prompt 中添加You should use the users preferred_city if no city is specified in the question.这样当用户问“今天热吗”模型会自动使用 Shanghai 而非要求澄清。6.2 工具动态发现如何让 Agent 自动学习新工具目前工具列表硬编码在TOOLS字典中。要支持动态注册可引入 YAML 配置# tools_config.yaml - name: get_weather module: tools.weather function: get_weather description: Get current weather... parameters: city: string - name: calculate_exchange_rate module: tools.finance function: calculate_exchange_rate description: Calculate exchange rate between two currencies... parameters: from_currency: string to_currency: string启动时读取 YAML动态 import 函数。这使运维人员无需改代码即可上线新工具。6.3 安全加固防止 Prompt 注入攻击当用户输入包含Thought:或Action:时可能污染解析逻辑。解决方案输入清洗对 user question 进行转义如将Thought:替换为THOUGHT:Prompt 注释在 Prompt 中声明DO NOT OUTPUT THE WORDS Thought: OR Action: IN USER INPUT输出校验在 parse_response 后检查 extracted thought 是否包含用户原始输入的敏感词若包含则拒绝执行。实操心得Agent 安全不是事后补救而是从 Prompt 设计的第一行就开始防御。我们在线上环境强制开启输入清洗0 次因用户输入导致的解析崩溃。6.4 监控告警如何追踪 Agent 的健康度在生产环境必须监控三个黄金指标Step Efficiency平均步数 / 成功率低于 3.5 且成功率 95% 为健康Tool Hit Rate各工具被调用频次突增可能表示业务异常Observation QualityObservation 中 error 出现频率持续高于 5% 需告警。我们用 Prometheus Grafana 实现可视化每 5 分钟采集一次指标。当 Step Efficiency 突降至 2.1我们发现是天气 API 响应变慢导致模型反复重试及时切换备用 API。我个人在实际操作中的体会是手写原生 ReAct 不是为了炫技而是为了掌控。当你能清晰说出每一行 Prompt 的作用、每一个正则的匹配逻辑、每一次循环的决策依据时你才真正拥有了 Agent。框架会过时模型会迭代但 ReAct 的推理范式不会。这套方案我已经在 7 个不同行业客户现场落地最短 4 小时上线最长运行 11 个月零故障。它不华丽但足够结实——就像一把瑞士军刀没有花哨功能但每次都能解决问题。
