王炸！Agent的本质竟是“花钱买大脑”？万字长文揭秘“用Token换架构”的底层逻辑！

关注

原创最新推荐文章于 2026-10-29 16:16:49 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

国内AI平台Plan机制深度解析：Coding/Agent/Token三类订阅技术本质 AI平台的‘Plan’已从简单计费单位演变为融合模型能力、调度策略与权限控制的技术封装单元。其底层涉及语义理解引擎、动态缓存网关、安全沙箱、工作流编排器及Token计数差异等关键技术原理，直接影响开发效能、系统稳定性与成本可控性。作为当前企业AI工程化落地的核心载体，Plan机制决定了代码补全准确率、Agent长周期记忆可靠性、长文本处理上下文利用率等关键指标。本文基于200人研发团队真实负载场景，实测火山、MiniMax、智谱等主流平台在Coding Plan、Agent Plan和Token Plan三阅读详情

市场今年刚看到Manus这种Agent的时候很兴奋，所以他们为什么这么兴奋？

Agent这东西又为什么会出现，他到底解决了哪一部分问题？其次，他到底能不能解决这些问题，在解决的过程中的困难与卡点是什么、又要如何解决？

带着上述问题，进入今天的学习：为什么需要Agent？

一、为什么Agent会出现？

模型当前虽然很强大，但他是天生缺陷的，他本身只包含了训练后的内置数据，这里就产生了第一个矛盾点：

当前社会信息爆炸太严重，一个星期就可以发生很多事，模型首先不可能跟得上这个节奏；其次他也不会去跟这些节奏，因为互联网上多数数据是垃圾，模型不可能去吃这些垃圾，垃圾吃多了会影响智商的；
除了市面上的信息，各个企业还有很多自己私有的数据，这些数据全部需要跟模型交互，否则在公司场景下模型的意义就不大了；

所以，Agent出现的第一个原因是，他至少需要与外部世界进行信息交流，尤其是一些垂直领域，如果数据不足，模型很容易胡言乱语的。

其实在这里很多同学是有疑问的，如果仅仅是这个原因，那直接采用Workflow的模式就好了嘛，这也是最标准的RAG逻辑嘛：

但就简单的信息检索这个需求，也是随时递增的，他现在拿的是公网数据，后续一会要拿A公司数据、一会要拿B公司数据，这种数据源变多了后怎么办呢？

谁去判断他应该去哪拿数据呢？这种让RAG系统处理起来就会很麻烦，比如以下问题：

什么是组织结构？你们公司的组织结构是怎么样的，A公司是怎么样的，B公司又是怎么样的?他们为什么要这么设计?

直接使用RAG也能做，流程是用模型判断到底有哪些问题，做下问题重写，分拆后再到各个信息渠道去获取信息，一套复杂的Workflow类RAG就能搞定。

这里关于Agent最深的冲突也就出现了：Agent能做的事情Workflow都能做，那么Agent存在的意义是什么？

毕竟，Workflow 可以做循环、可以做重试、可以做复杂策略，只不过这些循环与策略必须由人显式编码。当环境复杂度上升，Workflow 的成本曲线会很难看：

在企业真实场景里，复杂度增长通常来自三类“不可穷举”：

**工具/系统不可穷举：**今天查公网，明天查 A 公司的知识库、后天查 B 的 CRM、再后天接入 CDE……
**意图组合不可穷举：**一个问题里同时包含“解释概念 + 对比多家公司 + 要求给出原因 + 产出结构化表格”。
**异常与边界不可穷举：**权限不足、字段缺失、数据冲突、召回为空、网页结构变化、接口限流…

当然可以把这些都写进 Workflow，但会变成典型的分支爆炸 + 维护爆炸：

每加一个系统，不只是“多一个工具配置”，还包括字段映射、降级策略、评测集更新等。
更关键是：你要为“工具之间如何组合、何时重试、何时换路、何时追问补槽、何时拒答”写越来越多的显式编排逻辑。

这时候Agent架构的优势就出来了，如果多了CDE有可能增加3个工具配置，有可能什么都不做，搜索工具自己就兼容了。

最重要的是，判断用户意图和怎么调用工具，工具调用后的数据对不对这些繁琐的事情全部丢给模型了，当然循环肯定会多很多次、效率肯定要低点、Token肯定要高点，毕竟本身Agent就是一套时间/成本换架构简洁度的架构。

这里再加一句：Agent解决的不是怎么回答的问题，而是给出了一套将问题编译为可执行计划的框架，甚至于你把Agent这套架构本身理解为一套Workflow，也是可以的，这个是一套现阶段验证出来，很不错的范式。

最后再总结一下：相较于Workflow，Agent 架构是一种工程架构层面的优化，它的核心不是“更聪明”，而是把一部分原本由工程师在开发期显式写死的控制流（if/else、编排、异常处理），迁移到运行时由模型来决定（路由、工具选择、多轮尝试、失败重试、补槽追问、结果校验）。

Agent是用更多的成本（多轮推理 + 多次工具调用 + 更高延迟/Token），换开发与维护成本的下降（分支更少、扩展更快、长尾更适配）

在这个基础之下，我们再来看看整个Agent的发展史，这有助于我们进一步抓住其脉络。

二、Agent的发展史

当前最经典的Agent架构是ReAct，他大约是在2022年提出，论文《ReAct: Synergizing Reasoning and Acting in Language Models》。

那时候并不支持Function Calling这种最基本工具调用的能力，所以需要我们自己做实现，这里可以用提示词做识别并输出、也可以做微调（但成本要高点）。

其中Function Calling整体流程大概这样做的：

第一，我们会定义Agent会调用的所有工具，这是一个JSON对象，里面最核心的是description；

第二，模型会根据用户问题和预设的工具集去做对比，看看这次要调用哪些工具，当然最主要的还是根据描述判断；

第三，如果这次判断是有工具调用的话，模型会返回工具的名称，然后结束这次流程；

第四，我们拿着工具信息，去各种调用拿到数据，然后组装最终的提示词，连着用户的问题去做模型调用

只不过上述动作毕竟太繁琐，于是在23年6月，OpenAI提出了Function Calling，将他作为ChatGPT 产品的正式能力，后续逐渐成为事实上的标准，各个基座模型都有对应实现，有了这个基础后，Agent的出现就变得更加顺滑了。

而后的事情大家就很清楚了。国内Agent概念的火热从年初的Manus开始，但如果真要追溯早期、又出圈的Agent的话可以是2023年3月的开源项目Auto-GPT；

只不过就算今年的Manus在早期因为基座能力不足都表现不佳，遑论更早期的Auto-GPT了呢？

从Manus发布后，2025 AI应用元年逐渐转移成2025 AI Agent元年，模型也取得了长足的发展，包括整体的推理能力、上下文长度得到了极大的加强，而且我相信各个基座模型一定在工具调用这块做了大量微调训练，其直接的结果是下半年的工具调用能力有明显的加强。

在这个阶段，因为基座模型，大家发现Agent对工具的需求量极大，并且一定会产生很多类似的工具。

所以MCP的概念火了起来，一方面要解决之前Function Calling留下的工程维护问题，另一方面也想让人少开发工具，直接用社区的，MCP也几乎变成了事实上的标准，然后Agent发展进入了一个疯涨的阶段；

而后模型的稳定性调用能力有不小的加强，但在工具多了后依旧会有找不到、乱调用的问题。

于是Claude开始收集了大量Tools调优经验，在25年10月正式提出了Skills技术，可以认为他是在对整体Function Calling进行补足，当然Skills除了提升工具识别能力之外，还做了很多其他工作。

总之，现阶段使用Skills + Function Calling + 上下文工程，已经可以将准确率做得很不错了，比如我们就能折腾到90%+，这在之前是很难的，在工程上要做很多动作。

以上，是我从技术层面看到的，近三年Agent发展的情况，也就是说：在今年之前想要做出个好的Agent几乎不可能；在今年下半年开始，整体难度会小非常多；

最后这里的推测是：之前对于Agent的很多质疑乃至产品体验差的问题，在2026年应该会得到很大的缓解。

所以，要说Agent直接依赖于模型能力的变迁，这句话还真的没问题，你怎么优化都可能比不上模型一次能力升级。

了解了Agent为什么会出现，发展脉络是什么，也知道了几个关键点，接下来我们就来具体聊聊这几个关键点：Function Calling、MCP和Skills：

三、Function Calling

根据前面的描述，FC是干什么的大家已经很清晰了，单说FC其实就是用一套工程架构把之前模型判断（如何用工具）的工作流给替代掉：

具体的交互逻辑为：在对话中，LLM根据用户的问题（今天北京的天气如何？）判断是否需要调用函数。

如果需要，它会输出一个结构化的JSON请求，其中包含了要调用的函数名和参数，然后再调用我们的程序，整个官方的案例非常清晰：

具体的流程，直接看GPT官方的定义即可：

# 这是给模型看的工具定义，不是真正的代码tools = [{"type": "function","name": "get_weather","description": "Retrieves current weather for the given location.","parameters": {    "type": "object",    "properties": {      "location": {        "type": "string",        "description": "City and country e.g. Bogotá, Colombia"      },      ......    },  }}]

每次调用API时都需要传递tools参数，这里直接调用GPT接口（发起请求）：

# 每次调用API时都需要传递tools参数，调用GPT接口发起请求response = client.responses.create(    model="gpt-5",    messages=[...],    tools=tools  # ← 这个每次都要带)

这里也可以看出来，模型具有哪些工具调用能力，全部是我们预定义好的，模型会根据用户输入，选择使用哪个工具：

# 用户输入user_query = "今天北京天气怎么样？"# 模型会分析：# - 用户问的是"天气" → 匹配到 get_weather 的 description# - 提到了"北京" → 对应 location 参数# - 决定调用 get_weather 函数

只不过，模型事实上并不会直接调用工具，他只会返回结构化的调用指令，这里返回这个东西是模型专门任务训练的结果：

{  "function_call": {    "name": "get_weather",    "arguments": "{\"location\": \"北京\", \"unit\": \"celsius\"}"  }}

真正根据返回JSON数据调用脚本的是我们后台程序，并且这里需要将调用结果给到模型：

# 把天气结果返回给模型# result是返回的结果final_response = llm.chat(  model="gpt-5",  messages=[    {"role": "user", "content": "今天北京天气怎么样？"},    {"role": "assistant", "function_call": model_response["function_call"]},    {"role": "function", "name": "get_weather", "content": json.dumps(result)}  ])

逻辑很清晰，如果意图识别没有工具（函数）调用，则直接调用大模型返回给用户，如果判断有工具调用，那么就拿着首次模型返回的参数，拿到结果后二次调用模型，再将最终结果返回给用户。

这里有几个点要特别注意：如果你的工具接口挂了，容错做得不好的话，那么模型就不会回答用户了。

另外还有几个问题，理解后几乎就能了解Fuction Calling的本质，乃至为什么他用得不太频繁的原因：

第一，如果Tools工具过多（数组过多），这个也是要占用上下文长度的，所以真实使用会做很多小处理；

第二，Fuction Calling 使用好坏非常依赖于模型本身对意图识别的能力，模型判断要不要调用一个函数，主要是根据description参数来的。

这里看上去风险挺大的，因为一定会出现模型调用出问题的情况，只不过模型容错能力强，多拿了数据也未必会影响回答；

在这个基础下，我们再来说MCP和Skills，先说MCP：

四、MCP

那么MCP为什么会出现呢？这东西出现的意义是什么？要回答还得回归Function Calling…

关于Function Calling为什么会出现我们已经很清楚了，他解决的是：单个模型怎么“按你定义的 JSON 协议”去调你自己的API的问题。

但一旦工具变多后会有很多痛点：维护起来爆炸了！

MCP就是为了解决这个问题而生的，比较夸张的说法就是，MCP是帮Function Calling “擦屁股”的…

这里大家可能不太理解，给个案例：企业中有10个AI Agent（N）需要接入20个数据源/工具（M）。

如果每个应用都为每个工具编写专用适配代码，就需要200个集成点。这里面维护成本是较高的，任何工具API变更都会很烦。

并且要注意的是，生产上的Agent不会只调用一个模型，他可能同时调用ChatGPT、Gemini还有DeepSeek，而他们每个Tools调用接口都不一样，这个维护起来就更麻烦了。

在这个基础下，MCP出现了他引入“客户端-服务器”架构标准化。你只需编写一次MCP客户端，就能接入所有符合MCP协议的服务器。而工具提供者只需实现一个MCP服务器，就能被所有MCP客户端使用，集成点从N×M骤降到N+M。

案例说明

大家可能读起来有点迷糊，这里给个案例，这里有两个工具：

Tool A： get_weather(location) —— 查天气；
Tool B： get_stock_price(ticker) —— 查股价；

用户的问题是

“帮我查北京天气，再给我腾讯的股价，最后总结一下。”

传统的FC流程分四步：

一、预定义工具：

每次调用模型（或每个会话）都要把 tools 定义带进去：

tools = [  {    "type": "function",    "name": "get_weather",    "description": "Get weather by location",    "parameters": {"type":"object","properties":{"location":{"type":"string"}},"required":["location"]}  },  {    "type": "function",    "name": "get_stock_price",    "description": "Get stock price by ticker",    "parameters": {"type":"object","properties":{"ticker":{"type":"string"}},"required":["ticker"]}  }]

二、模型返回“工具调用指令”（结构化 JSON）

{  "tool_calls": [    {"name": "get_weather", "arguments": {"location": "Beijing"}},    {"name": "get_stock_price", "arguments": {"ticker": "AAPL"}}  ]}

三、我们自己后台程序做工具调用

def get_weather(location):    return weather_api.query(location)def get_stock_price(ticker):    return market_api.query(ticker)

四、拿到工具结果，组装提示词最终调用模型生成回答

tool_results = [  {"name":"get_weather", "content": "..."},  {"name":"get_stock_price", "content": "..."}]final = llm_call(messages + tool_results)

如果，这个工具只服务了一个Agent，那没问题，但如果服务了2个就会麻烦一点：

比如在工具参数变了的时候，他就要改2个Agent的配置了，如果应用变成20个的话就很麻烦了，因为我们大概率也记不清楚谁在调用工具了…

如果有MCP后，就简单很多了，他用工程的方式把一些复杂的维护封装了：把 Tool A/Tool B 的接入从“应用内部代码”搬到“独立的 MCP Server”里。

AI 应用不再直连 Weather API / Market API，而是只连 MCP Server。

这里其实逻辑很简单，甲乙双方之前口头约定参数，然后两边写，下游发现老是被坑，就说你他妈别约定了，参数是什么，你一起传给我算了！

Agent也不直接连接工具AI了，只连接MCP Server，可以把 MCP 当成一个“工具总线”：

MCP Server（工具提供者）：暴露工具列表 + 接受调用 + 返回结果
MCP Client / Host（AI 应用）：连接 server、发现工具、转发调用、回传结果给模型

方便大家理解，这里依然走个流程：

一、MCP Server 暴露工具

Weather API / Market API 的鉴权、重试、字段映射，都封装在 server 里
外界只看到“标准化工具”：名字、参数 schema、描述、调用结果

# mcp_server.py@tool("get_weather", input_schema={"location":"string"})def get_weather(location):    return weather_api.query(location)@tool("get_stock_price", input_schema={"ticker":"string"})def get_stock_price(ticker):    return market_api.query(ticker)run_mcp_server(transport="stdio")  # 或 HTTP/SSE 等

二、Host连接MCP Server，并发现工具

client = MCPClient(connect="stdio:python mcp_server.py")tools = client.list_tools()# tools -> [{name, description, input_schema, ...}, ...]

三、把发现到的工具“翻译/映射”给当前使用的模型平台

如果你用 OpenAI，就把它们组装成 OpenAI 的 tools 数组
如果你用 Claude/Gemini，就组装成各自需要的声明格式

注意：这一步仍然需要做“向上适配模型”，但这是一层通用适配，不会因为 Tool A/Tool B 的内部细节而变化。

四、模型基于工具合同做决策，返回 tool_call（name + arguments）

{  "tool_calls": [    {"name": "get_weather", "arguments": {"location": "Beijing"}},    {"name": "get_stock_price", "arguments": {"ticker": "0700.HK"}}  ]}

五、Host 不再直连外部 API，而是把调用转发给 MCP Server

for call in tool_calls:    result = client.call_tool(call["name"], call["arguments"])    tool_results.append({"name": call["name"], "content": result})

至此基本结束了，其实大家也看出来了，Agent这东西黑盒是真的多啊…

遗留问题

虽然MCP确实可以解决工具过多的维护问题，但他并不能解决工具多了，乱调用、错调用的问题，而且还会有工具过多时候的爆炸问题，工具如何组织的问题。

当然，在比较差的架构下（团队能力不行），FC要求开发者在每次API调用时预先声明所有可用工具。

但这个是可以被优化的，也就是每次用户问题要过一次模型，判断这次到底要用哪些工具，要用才加载，只不过可能会有错漏。因为这个机制也能做到动态添加/移除工具。

但这一切依旧不太优雅，工具调用还是老是出问题，所以在MCP之后又有擦屁股的工程能力诞生了，他的名字叫：

五、Skills

我们前面说了，用户无限的意图需要用有限的工具来收敛。

只不过工具多了后，排列组合也多，收敛不收敛不知道，Agent最大诟病就是工具调用不准、Agent整体响应慢倒是真的，为了解决这一切，又叠加了一个新的工具：

Anthropic 对Skill的定义是：一个文件夹，里面装着说明文档、脚本和资源，Claude 在执行任务时会先扫一圈所有 Skills，觉得哪个对当前任务有用，就把完整内容拉进上下文来用。

翻译翻译是：

Skill = 一份可反复调用的专业SOP＋说明书，由模型自己按需加载

结合之前我们说Skills的诞生原因，其实就是将工具调用不准的问题搬到了Skills里面，不需要模型自己去语义理解自己做工具组合了，Skills里面写得很清楚，该用什么工具、怎么用，这样就会缓解之前的工具错误。

当然除此之外，Skills还有其他意义，总结下来Skills诞生的原因有：

一、提高工具调用稳定性

绝大多数团队都会面临，一旦Tools多了后就会束手无策，他们会被“乱调用/漏调用/参数错/顺序不稳/失败不重试”折磨，直接导致体验差、不可交付。

Skills 的核心价值之一就是把“怎么用工具把事做对”的套路（选择条件、步骤、校验、兜底）沉淀成可复用模块，从而显著降低随机性。

其实这个之前是做到ReAct工程架构里的，现在有Skills，可以有效降低工程难度；

只不过要特别注意，Skills也不能彻底解决Tools调用错误问题，还得有其他工程手段。

二、长提示词与硬编码流程的维护问题

关于这点，很有点之前MCP出来的重要原因，都是项目大了会导致的烦躁工程维护问题。

维护提示词多的同学会有感受，现在提示词正在往伪代码的方向发展，为了让模型稳定输出，需要往里面不断加东西，比如一个数据分析的案例：

业务规则：指标口径、过滤条件、时间粒度
数据规则：字段映射、缺失值处理、异常检测
工具规则：SQL 工具怎么用、什么时候用、失败怎么重试
输出规则：必须给表格、必须给结论、必须给风险提示
合规规则：脱敏、禁用词、免责声明
还塞一堆示例（few-shot）

结果：

上下文常驻：每次对话都带着一大坨“未必用得上”的规则，成本高、干扰大
版本不可控：某个字段改名了、口径变了，你改 Prompt，影响全局，回滚困难
复制漂移：A 项目 copy 一份，B 项目再 copy 一份，三个月后都不一致
排障困难：出错了不知道是“规则写错”“规则太长模型没读到”“示例冲突”还是“工具返回异常”

Skills的解题思路就跟之前MCP很类似了，把所有的这类配置信息全部写到统一的地方，需要用到时候再拿出来。

另一个角度，既然提示词现在越来越像代码工程了，那么对应的版本管理的概念就会出现，包括追求的灰度和回滚等问题，而Skills正是处理提示词工程管理复杂而诞生的。

这里给个案例做，为什么需要Skills的说明：

案例对比

帮我查一下技术部张三上周的差旅报销总额，然后按项目拆分一下

这里直接使用FC的话：

[  {    "name": "get_employee_info",    "description": "获取员工基本信息",    "parameters": {      "employee_name": "string"    }  },  {    "name": "get_department_info",     "description": "获取部门信息",    "parameters": {      "department_name": "string"    }  },  {    "name": "query_reimbursements",    "description": "查询报销记录",    "parameters": {      "employee_id": "string",      "start_date": "string",      "end_date": "string"    }  },  {    "name": "query_projects",    "description": "查询项目信息",    "parameters": {      "department_id": "string"    }  },  {    "name": "analyze_reimbursement_data",    "description": "分析报销数据",    "parameters": {      "reimbursement_data": "array",      "group_by": "string"    }  }]

在ReAct架构中需要自己去实现正确的调用逻辑：

先调 get_employee_info(“张三”) 拿到员工ID
调 get_department_info(“技术部”) 拿到部门ID
调 query_reimbursements(employee_id, 上周起止日期) 拿到报销列表
调 query_projects(department_id) 拿到项目列表
调 analyze_reimbursement_data(…) 进行分析

这里常见问题就产生了：

**乱序调用：**先查项目，结果没部门ID参数
**参数错误：**时间格式不对（“上周” vs “2025-12-08”）
**漏调工具：**忘记调analyze直接返回原始数据
**无限循环：**某个工具失败后不会自动重试或换方案

能不能解决呢，也是可以的，但会加大工程复杂度，可能加大循环次数，最终响应速度和成本都会有影响。

而使用Skills后，相当于认为的为这个需要加了一套强的工作流，或者CoT：

用户: "张三上周差旅报销"模型: 检测到"报销"关键词 → 加载"报销查询"Skill按Skill流程执行:1. 自动调用get_employee_info("张三") → 拿到ID: 1232. 自动调用时间解析("上周") → 得到: 2025-12-08 ~ 2025-12-14  3. 调用query_reimbursements(employee_id=123, start_date=..., end_date=...)4. 发现用户没提"项目" → 跳过项目拆分步骤5. 调用标准化报告模板生成结果直接返回: "张三上周差旅报销总额5,200元，共3笔..."用户体验: ✅ 好 - 一次搞定

CoT都出来了，稳定性肯定高啊！

这里再说下维护性问题，如果财务的差旅标准变了，之前所有涉及提示词部分的数据需要改，但用Skills就只需要改一个地方，很清晰的。

其他案例

在一个老板 BI Agent里配置了，一批 Tools/MCP 工具：

get_sales_report
get_marketing_spend
get_cashflow_status

两个 Skills：

boss_bi_dashboard_cn：教模型如何用上面几个工具，按老板视角解释数字、写结论，里面有详细的 KPI 口径、话术、注意事项；
excel_analysis_skill：教模型如何用 code execution 对上传的 Excel 做分析；

这时候触发条件来了：帮我看看今年 Q3 的营收和投放，简单说说是不是该收一收预算？这里具体的流程是：

一、先走Skill检索

模型首先会理解，这是一个老板视角的财务分析 + 决策建议，接下来模型会遍历Skills里所有的meta，发现 boss_bi_dashboard_cn 的描述里有类似：

用于解读公司经营指标、营收、成本、预算，输出老板视角决策建议

所以它会激活这个 Skill，读取 instructions.md，把这份“说明书 + SOP”拉进当前上下文。

此时，Tools/MCP 还没被调用，模型完成了：从很多工具定义 + 一堆 Skills里，选出一个最合适的技能包。

二、Skill里面决定工具调用

boss_bi_dashboard_cn 的 instructions.md 可能会写类似这样的话：

如果用户问的是某个时间段的“营收 + 投放”，先调用 get_sales_report 拿营收数据，再调用 get_marketing_spend 拿投放数据；然后根据「同比 / 环比 / ROAS」给出老板能看懂的判断；输出结论时，要用以下结构：一句话结论2–3 个关键数字建议动作风险提示

Claude 读了这份说明后，就知道下一步应该：

先查 KPI → 需要工具；
然后就是具体工具调用：

get_sales_report({"period": "2024-Q3"})get_marketing_spend({"period": "2024-Q3"})

到这里Function Calling / MCP 出场了。

三、数据处理 + SOP

这里走Function Calling的逻辑拿到最终反馈数据即可（这里不展开）：

{  "sales": 12345678,  "growth_rate": 0.12,  "gross_margin": 0.31}

然后就是数据使用，这个instructions.md里面已经说得很清楚了：

输出结构怎么写；哪些数字要重点强调；语气要偏老板视角，少讲实现，多讲结论和动作；有哪些“常见坑”要避开；# 输出案例结论：Q3 的营收仍在增长，但投放效率明显走低，建议适度收缩预算、把钱放到 ROAS 更高的渠道上。......后面是建议 + 风险......

以上就是Skills，相信大家搞懂了，最后说下Agent架构的核心：ReAct。

六、ReAct框架

了解了Agent的最原子能力依赖后，我们就要进入其真正的编排层核心ReAct了：

编排层是智能体系统的核心控制单元，负责组织信息流和执行推理循环。它模拟人类在做复杂任务时的认知过程：先获取信息、然后制定计划、执行行动、再根据反馈调整计划，不断循环直到完成目标。

一个常见的比喻是**“厨师准备复杂菜品”**：厨师会根据顾客需求获取食材信息，思考烹饪步骤，然后实际烹饪，过程中可能根据味道反馈不断调整方法。

类似的，Agent的编排层会按照设定的推理框架反复迭代，驱动模型生成“思考”并做出“行动”决策。

常见的推理框架大同小异，这里一定需要了解的是两个东西ReAct与CoT，除此之外可以延伸到ToT：

ReAct在前面我们做了基础介绍，该框架强调模型在回答前进行连续的内省和行动选择，有助于提高答案的准确度和可追溯性；

**CoT（思维链）**引导模型通过生成中间推理步骤来分解问题，促使其在最终答案前先列举思考过程，这种框架可以增强模型解决复杂问题时的准确性（幻觉问题）。

**ToT（思维树）**是在 CoT 的基础上，允许模型在多个备选思路间做比较，适用于需要探索多种方案的策略性任务，目的依旧是提升对复杂问题的解决能力。

篇幅有限，我们只讨论ReAct和CoT的配合即可（其他的都类似）：

ReAct和CoT

首先，ReAct与CoT都是推理策略框架也就是Agent四大组件核心的编排层具象化实现，他们都描述的是如何组织模型的推理过程、生成步骤、提示词结构。

换句话说，ReAct是代码的核心，是AI工程的核心，他会决定如何去与记忆系统、工具系统做配合。

然后，ReAct逻辑上与CoT是同级别的，但现在更多的是在组合使用，显得CoT是ReAct的一个过程产物，其实并不是的，逻辑上CoT也可以调用工具；

只不过现在从流行范式的角度来说，ReAct被用作主框架的时间会多一点，并且过程中会包含很多CoT的部分，这里的结果是：ReAct 是容器，CoT 是内容。ReAct 是最“Agent”化的、CoT 是最基础的。

ReAct 规定了：先思考（Thought）→ 行动（Action）→ 等待结果（Observation）→ 再思考…

而这个“Thought”怎么写？通常就是一个 Chain of Thought 推理块。

举个简单例子：让 Agent 回答“某公司员工请假流程”的问题，Agent 需要：

读取用户的问题
从知识库中检索文档
分析内容结构
输出清晰步骤

这块的简要流程是：

User: 请问我们公司请假流程是什么？Step 1:Thought: 先查找关于“请假流程”的文档。Action: search_docs("请假流程")Observation: 找到文档《员工手册》第4章，列出了流程步骤。Step 2:Thought:首先读取这部分内容，理解流程的顺序。- 第一步是员工提交请假申请- 第二步是直属上级审批- 第三步是HR备案因此我可以组织一份清晰的回答。Action: NoneFinal Answer: 请假流程如下：1）提交申请；2）主管审批；3）HR备案。

这个 “Step 2” 的 Thought 部分就是一个简单的 CoT，模型在没有行动前，分步思考、提取、组织信息，这是典型的思维链。

为什么这么用也很简单：Agent架构中也不可能每一步都调用工具，很多时候只是在“组织思维/语言”，CoT可以有效降低幻觉率。

总而言之，ReAct 框架里可以有很多 CoT 内容穿插其中，这种组合也是最常见、最稳的做法，大家记住这点就行，这就是Agent的编排层。

七、结语

然后就是记忆系统了，这个其实才是整个Agent项目里面最恼火、最烦躁的部分，因为太过于复杂，我们今天就不继续了，后面有专门的课题。

最后总结一下：市场之所以为 Manus 这类 Agent 兴奋，不是因为它“更聪明”，而是因为它把原本需要工程师在 Workflow 里写死的路由、工具选择、重试等控制流，迁移到运行时由模型来决定，从而在“工具多、意图组合多、异常多”的企业场景里显著降低开发与维护成本。

过去三年的脉络也很清晰：ReAct 提供推理+行动的循环框架，Function Calling 让工具调用标准化，MCP 缓解工具爆炸带来的集成维护成本，Skills 把“怎么把工具用对”的 SOP 沉淀下来提升稳定性。

25年工具调用这块模型已经取得了长足进步，但记忆模块依旧是老大难问题，我认为2026年，底层模型一定会在这块做出突破，那种本地部署的模型（高阶向量数据库）是可能诞生的，让我们拭目以待吧…

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述