前面2篇讲到了Planner + Router + Executor 这3个组合起来就能构建真正可执行、可扩展的智能体系统。规划有了，工具也定义好了，接下来就是如何让智能体按照规划一步一步调用工具来实现功能。只有让任务真正发生，而不是变成“语言幻觉”
Planner 会告诉模型 “怎么做”， Router 会告诉模型 “用什么工具”， Executor 才是让任务真的发生的模块。
70% 的智能体项目都停留在“模型说自己做了”，但实际上任何操作都没发生。 这是为什么？因为他们只完成了 Planner + Router，却没有把 工具执行、异常管理、状态存储、回溯机制 构建起来。 今天这篇文章，就是解决这个问题。我会把执行器的底层设计，从体系到代码，一次讲清楚。
🚀 1. Executor 的职责是什么？
执行器就是智能体的“肌肉”。它接收 Router 的输出，进行：
✔ 1. 工具调用
运行：
- Python 函数
- API 调用
- DB 操作
- 外部系统（飞书、Notion、Slack）
- 文件操作
- 机器人任务（Android、Web 自动化）
✔ 2. 异常处理（最核心）
包括：
- 工具参数异常
- 网络超时
- 工具内部报错
- API 限流
- 非预期输出
- 空结果 没有异常机制的智能体一定会“死”在流程中。
✔ 3. 输出转结构化结果（Return Schema）
模型不认识 Python 的返回值， 你必须在 executor 做一次格式化。
✔ 4. 状态存储与回溯
必须保存每一步：
- 输入
- 工具
- 参数
- 输出
- 错误 这让整个 agent 可追踪、可重放、可 Debug。
🚀 2. Executor 的通用流程（标准化）
这里给你一个黄金流程（适用于所有 Agent 框架）：
┌───────────────────────┐
│ Router Output (JSON) │
└───────────────────────┘
│
▼
┌───────────────────────┐
│ Validate Arguments │ 参数校验
└───────────────────────┘
│
▼
┌───────────────────────┐
│ Execute Tool │ 工具执行
└───────────────────────┘
│
▼
┌───────────────────────┐
│ Catch Exceptions │ 异常处理
└───────────────────────┘
│
▼
┌───────────────────────┐
│ Save State / Log │ 状态存储
└───────────────────────┘
│
▼
┌───────────────────────┐
│ Return to Orchestrator│
└───────────────────────┘
Executor 决定了你的智能体是不是“工程可控”。
🚀 3. Executor 的核心规则（必须遵守）
下面三条是工程中最关键的原则：
⚠ 1. 工具必须是纯函数（Pure Function）
怎么理解：
- 相同输入 = 相同输出
- 不依赖全局状态
- 不产生不可控副作用 智能体在执行过程中可能会：
- 重试
- 反复调用
- 根据结果判断下一步 如果工具不是纯函数，整个智能体无法调试。
⚠ 2. 工具执行必须有超时机制
绝大多数挂掉的 Agent，都是卡死在：
- 网络超时
- 数据库阻塞
- 文件锁死
- API 一直不返回 所以你必须：
- 为每个工具设定 timeout
- 超时自动重试或抛错
必须有fallback机制
⚠ 3. 工具输出必须结构化（JSON）
不要让模型去解释 Python 对象。 Executor 要确保输出格式如下：
{
"status": "success",
"data": {
...}
}
🚀 4. Executor 的 Prompt 结构（模型增强型执行器）
如果你的执行器依赖模型来“解释结果”，下面是一个工程级 Prompt：
你是 Executor，你的任务是执行 Router 指定的工具，并将执行结果规范化。
规则：
1. 必须严格使用 JSON 输出
2. 成功时输出:
{"status": "success", "data": ...}
3. 失败时输出:
{"status": "error", "message": "..."}
4. 不得幻想不存在的执行结果
5. 不能替代工具执行，只能处理执行后的数据
这个 Prompt 会让模型对执行后的内容做结构化处理。
🚀 5. Executor 的代码结构（标准 Python 模板）
一下是一个企业级智能体执行器的标准实现：
import json
import traceback
class Executor:
def init(self, tools):
self.tools = tools # dict: {tool_name: function}
def execute(self, task):
tool_name = task["tool"]
args = task["arguments"]
if tool_name not in self.tools:return self._error(f"Tool {tool_name} not found")
tool = self.tools[tool_name]
try:
result = tool(**args)return self._success(result)except Exception as e:return self._error(str(e), traceback.format_exc())
def _success(self, data):return {"status": "success","data": data
}
def _error(self, msg, tb=""):return {"status": "error","message": msg,"trace": tb
}
工具统一接入：
def crawl(url): ...
def analyze(text): ...
def save_to_db(obj): ...
executor = Executor({"WebCrawler": crawl,"TextAnalyzer": analyze,"DBWriter": save_to_db
})
🚀 6. 最难的部分：异常管理（工程实战）
智能体不是线性的，失败率远比普通程序高。 所以我建议采用 智能体的 3 层异常体系：
① 工具级异常（Tool Error）
如：
- 参数不合法
- 网络失败
- 文件不存在 解决方案：
- try/catch
- 统一返回 error JSON
② 流程级异常（Agent Error）
如：
- Planner 出错
- Router 产出非法参数
- Executor 多次失败 解决方案：
- 生成新 step（模型修复）
- 回退上一状态
- 触发“Fallback Prompt”
③ 人类审核（Human-in-the-loop）
涉及到一些敏感操作：
- 高风险 API（发邮件、退款、数据库写入）
- 创建社交媒体内容
- 生成业务报告
- 财务结果
- 风险内容 必须有对应安全机制：
- 所有高风险工具 → 必须人工审核
- Executor 只负责“生成待执行内容”
- 人类点击确认 → Executor 执行最终版本
🚀 7. 加上状态管理（State Manager）后，Agent 才真正可用
Executor 在执行每一步时必须写入日志：
{
“step”: 3,
“tool”: “WebCrawler”,
“input”: {…},
“output”: {…},
“error”: “…”
}
写日志是为了：
- 故障排查
- 用户可视化
- 自动回溯
- 重放任务
- 训练数据记录
- Prompt 改进 都依赖这些中间状态。
🚀 8. 最佳实践（非常关键）
✔ 1. 工具必须可测试（单元测试）
AI 只是 orchestrator，核心逻辑应该可测试。
✔ 2. 工具必须小而精准
每个工具做一件事，越大越不稳定。
✔ 3. 工具返回必须稳定类型
不能某次返回 list，下次返回 dict。
✔ 4. Executor 必须与 Planner 解耦
Planner 崩了不影响工具，工具崩了不影响 Planner。
✔ 5. 错误要尽可能“结构化”
要避免出现：
Exception: Something wrong
正确的方式是：
{"error": "network_timeout", "detail": "..."}
最后，Executor作用是让“智能体从语言变成行动” 到现在，你已经有：
- Day 4 → Planner（任务分解）
- Day 5 → Tool Router（选择工具）
- Day 6 → Executor（工具执行 + 异常处理） 三件事合起来： 你的智能体已经具备完整“感知 → 计划 → 执行”链路。 这是市面上 95% 号称“智能体”的系统都没有做到的工程能力。
