大家好，我是吴师兄。
最近在做 Agent 系统的同学，非常容易遇到一个现实问题： 模型会调用工具，但常常“用不对”。
要么顺序错了、要么参数缺了、要么把两步操作混成一步、要么中途报错后不会自救。
只要遇到“中等复杂度”任务，比如：
“查一下明天从上海到北京的航班，订最便宜的，然后再帮我订机场附近的酒店。”
模型就会直接乱套。
但有趣的是，在吴师兄大模型训练营的多个 Agent 项目里，只要加上 CoT + Plan-Execute （即 思考链 + 计划执行） 这两个组件，Function Call 的正确率能从 50% 提升到 90%+。
这篇文章就来聊清楚：
-
为什么 CoT 是 Function Call 的必要条件？
-
Plan-Execute 到底解决了哪些经典 badcase？
-
企业级 Agent 为什么都在用 CoT？
-
面试官听你讲这套逻辑，会直接知道“这人真干过”。
模型为什么会乱？因为它不知道“步骤有顺序”
LLM 本质上是一个“生成模型”，不是一个“任务规划器”。
当用户给出多步任务时：
查航班 → 订机票 → 查酒店 → 订酒店
模型的直觉是：
我一个回答里搞定全部不行吗？
于是你会看到这样的 Function Call：
book_flight(origin="上海", hotel_city="北京机场", date="明天")
参数混在一起、顺序错乱、信息缺失，典型的“模型拟合出来的自信幻觉”。
这不是模型蠢，而是没有告诉它：
-
这是多步任务
-
要逐步思考
-
每一步都要通过工具执行
-
上一步结果会影响下一步
这就是 CoT + Plan 的意义。
为什么 CoT（Chain-of-Thought）能让模型“变聪明”？
CoT 的本质，就是让模型先写“草稿”，再决策。
比如：
用户说：
“帮我订明天从上海到北京的航班，然后订一个机场附近的酒店。”
模型先输出 Thought：
Thought: 用户需求分成两个步骤：
- 查询明天从上海到北京的航班
- 订机票
- 查询北京机场附近的酒店
- 订酒店
这一步非常关键，因为：
在 Thought 阶段，模型不会执行动作，只会规划任务。
这就避免了模型“急着给动作”的毛病。
只要你让模型先把事情讲明白，它出错的概率就会大幅下降。
在训练营里我们做过大量实验：
-
不加 CoT：模型常常一次性乱调用
-
加了 CoT：基本都能拆成正确步骤
这就是“让模型先讲理由”的威力。
Plan-Execute：让模型“按步骤做，不越界跳步”
仅有 CoT 还不够，因为有些模型虽然“想对了”，执行时还是会乱。
所以我们引入 Plan → Execute → Observe → 修正 的循环。
流程如下：
Step1：Plan（规划）
模型输出所有步骤（不调用任何工具）
Step2：Execute（按顺序执行）
系统逐条调用工具 模型不允许跳步、不允许合并步骤
Step3：Observe（接收 API 返回）
系统把 API 结果反馈给模型
Step4：Reflection（模型自我修正）
模型看到错误，例如：
error: PAYMENT_FAILED
它会重新规划下一步：
Thought: 需要尝试备用支付方式 Action: book_flight(..., payment_method="backup_card")
这种能力比 LLM 一口气去做所有事情稳定得多。
真实案例：没有 CoT + Plan-Execute，模型会怎样？
下面是训练营里的真实 badcase：
用户说：
“帮我订一个明天从上海到北京的机票，然后订一个机场附近的酒店。”
模型直接输出：
book_hotel(hotel_id="？？", date="上海到北京", guest_name="三天")
完全失控。
但当加上 CoT：
Step1: 查航班 Step2: 订航班 Step3: 查酒店 Step4: 订酒店
再加上 Plan-Execute：
-
查航班 → API返回结果
-
订航班（失败）→ 自我修正
-
查酒店 → 正常执行
-
订酒店 → 成功
从一团乱麻变成可控执行链路。
为什么企业级 Agent 必须用这套玩法？
越是大型、越是复杂、越是安全要求高的场景，越必须使用 CoT + Plan-Execute。
比如：
-
订单自动化系统
-
财务报销机器人
-
医疗咨询助手
-
客服多轮处理系统
-
法律问答 + 工单流转
因为这些任务本质就是：
多步骤 + 状态依赖 + 多工具协同 + 出错必须可恢复。
没有规划、没有观察、没有反思，就无法保证：
-
正确性
-
稳定性
-
过程可控性
-
错误可以定位
这是为什么当企业面试听到这句话，会立即加分：
“我们用 CoT 做任务拆解，用 Plan-Execute 控制调用顺序，用 Observation 做错误回馈，用 Reflection 做自我修正。”
能讲出这句话的工程师，基本都是做过实际落地的。
总结：CoT + Plan-Execute 是 Function Call 的“操作系统”
一句话总结：
没有 CoT，模型不知道怎么拆任务；没有 Plan-Execute，任务拆对了也跑不稳。
1、CoT 让模型“讲清楚任务”
2、Plan 让模型“按顺序做任务”
3、Execute 让模型“逐步执行工具”
4、Observe 让模型“看到 API 结果”
5、Reflection 让模型“自己修正错误”
这套闭环，就是现实世界 Agent 系统的“操作系统”。
在吴师兄大模型训练营的 Agent 项目里，这套体系是强制要求写在系统 prompt、执行链路里的，因为：这套方法，不是为了炫酷，而是为了能稳定跑。