主要讨论：什么是 Agent、为什么不是一步生成、为什么需要 tool 和 planning、Agent 与 workflow 的关系

Agent 的本质

Agent 的本质，不是“会调用模型”，而是“围绕目标持续决策的执行系统”

很多人一开始做Agent，路径都差不多

• 先接一个模型，让它回答问题
• 发现纯回答不够，就加prompt约束
• 然后为了拿到实时信息或者业务数据，再接工具
• 接着为了让体验更像智能体，做多轮上下文、历史记忆、自动重试

但是实际上这个可能是个增强版的生成系统，而不是一个真正的目标驱动执行系统

一个更准确的定义应该是这样的：

Agent 是一个以目标为中心的执行系统。模型在其中不是单纯的内容生成器，而是负责持续做局部决策；系统则负责把这些决策转成受控动作，并在外部反馈回来后更新状态、修正路径，直到目标完成或触发终止条件。

OpenAI 官方在 function calling / tools 文档里强调，tool calling 的意义是让模型与外部系统和外部数据交互；Agents 文档则明确把 agent workflows、monitoring、optimization 放到一起，说明今天的官方心智模型已经不是“生成文本”，而是“围绕任务组织执行”，这个定义的价值，在于它把“生成”降级成了系统中的一个环节，而把“目标、决策、动作、反馈、状态、终止条件”提升成了主角

什么是一步生成？什么是多步执行？

一步生成：模型在一次调用里，直接生成最终结果

但是实际上agent并不是一步生成的，他通常需要多次决策+多次执行+多次反馈来获取足够的信息，是逐步执行下去的，因此属于是多步执行

而作为多步执行，才需要对系统进行控制，因此才会进一步涉及到

• Runtime
• 状态机
• 死循环
• 失败回复

Tool/Namesapce/MCP

Tool caling的本质

tool call干的事情实际上就是调api，他本质上是为了让模型更像人，OpenAI 官方对 function calling 的定义就是：模型通过结构化 schema 与外部系统交互，这使得应用可以把自然语言意图映射到程序动作，而不是依赖模型输出一段模糊文本让下游再猜

所以Tool cal本质不是给模型多几个能力，而是负责把模型的自由输出空间约束成受控的动作空间，模型负责决定要不要做某个动作，而系统负责用schema、参数校验、权限控制和执行结果把动作落地

这句话里面有两个层次。第一层是“动作空间约束”。这是最关键的，因为语言模型原本输出的是开放文本，它擅长表达，但不天然适合直接驱动系统。只要你让模型随便输出文本，系统就很难做权限、审计、幂等、参数校验，也很难知道它到底是“建议你查天气”还是“真的要调用天气服务”。工具 schema 的作用，就是把这种开放文本压缩成一组离散动作。第二层是“治理”，由于动作是结构化的，才会进一步衍生出后续的一系列超时、重试、审计、风控、降级

tool越多越好吗

参考https://openai.github.io/openai-agents-python/tools/?utm_source=chatgpt.com

OpenAI Agents SDK 的文档就建议优先用 namespace 或 MCP，而不是无节制地堆很多零散函数，因为太多工具会让模型的选择空间膨胀，增加 token 消耗和错误选择概率

工具不是越多越好。工具集合本质上也是模型的搜索空间，过多工具会增加选择难度和误调用概率。更合理的做法是按领域分组、控制单个命名空间的复杂度，并用策略层或 router 缩小候选集。

那这里提到namespace和mcp，就要进一步介绍一下tool/namesapce/mcp了

Tool/Namespace/Mcp

tool 是模型可调用的“动作单元”；namespace 是把一组相关 tools 打包成一个更高层的“工具域”；MCP 是一种标准协议，用来把外部系统里的 tools 和 context 以统一方式接进来。

在 OpenAI Agents SDK 里，namespace 解决的是“函数太多、描述太散、token 太贵”的组织问题；MCP 解决的是“工具来自外部系统、希望标准化接入”的集成问题；而不管工具来自本地函数还是 MCP 服务器，最终它们都会以“模型可见、可调用的 tool surface”形式呈现给 Agent。

tool 是最底层的执行单位。

它表示“模型如果决定做某件事，可以调用这个能力”。这个能力可以是一个本地函数，比如 get_customer_profile，也可以是一个 hosted tool，比如 web search、file search，甚至也可以是一个通过 MCP 暴露出来的远程工具。对 Agent 来说，tool 的核心含义只有一个：这是一个可选动作。 SDK 的 Agent 配置里也直接有 tools 字段，表示“这个 agent 可用的工具列表”。

namespace 不是新类型的工具能力，而是一个工具组织方式。

OpenAI Agents SDK 在工具搜索（tool search）场景里提供 toolNamespace() / tool_namespace()，作用是把多 个相关函数工具放进一个共享名字和共享描述下面，让模型先看到一个高层的“工具域”，例如 crm、billing、shipping，而不是一上来就暴露几十个零散函数。文档里明确说：当多个相关工具应该共享一个领域描述并作为一组被加载时，用 namespace；当某个工具本身就是一个独立能力、名字本身就很好搜索时，才保持顶层单工具。

MCP 也不是某一个具体工具，而是一种标准协议和接入方式。

OpenAI Agents SDK 文档把 MCP 定义为一个开放协议，用来标准化应用如何向 LLM 提供 tools 和 context；SDK 支持多种 MCP server 形态，Agent 运行时会把这些 server 上暴露的工具纳入可用工具列表。也就是说，MCP 更像是“工具总线/接口标准”，而不是“某个函数”或“某个命名空间”

所以最简单的理解是：

• tool：模型能做的一个具体动作
• namespace：把一组相关动作打成一个工具域
• MCP：把外部工具系统标准化接进来的协议

Planning

planning 解决的是不完全信息条件下的执行组织问题。当模型面对的是多步任务，它不能只靠局部贪心决策一路往前走，否则很容易在中间浪费步骤、错用工具或走到死胡同。Planning 的意义在于，先形成一个相对粗粒度的目标结构，再在执行过程中根据 observation 局部修正。

我们可以把 planning 分成三层去理解。第一层是目标分解：把“帮我完成一件事”拆成可验证的子目标。第二层是顺序组织：先做什么、后做什么，哪些步骤可以并行，哪些必须串行。第三层是动态修正：不是一开始列完计划就机械执行，而是允许因为新 observation 而 re-plan。LangGraph 把 workflow 建模为 graph，本质上就是把“计划”和“控制流”显式化：有节点、有状态、有边、有分支，而不是把所有逻辑都塞进一段 prompt。

planning和workflow

Planner 解决的是“在当前任务上下文里怎么组织步骤”，Workflow 解决的是“系统整体允许哪些路径、哪些边界、哪些中断和回退规则”。前者更偏任务级策略，后者更偏系统级控制。

Agent 和 Workflow 到底是什么关系

Workflow 负责确定性的系统控制，Agent 负责不确定性的局部决策

Workflow 擅长的是：定义边界、组织顺序、治理权限、提供审计、做重试和回滚。Agent 擅长的是：在边界之内处理高不确定任务，比如信息不足时该先查什么、多个工具中先试哪个、当前 observation 是否足以得出结论。LangGraph 的设计很能说明这一点：它不是在鼓励你“不要 workflow，只要 agent”，相反，它是把 agent workflows 显式图化、状态化、可持久化

当任务路径基本固定、业务规则明确、异常模式可穷举时，更适合直接用 workflow。Agent 应该用在规则难以穷举、对中间反馈高度敏感、或者需要动态工具选择的部分。否则引入 Agent 只会增加不确定性和调试成本。

Agent 不是普通的模型调用链，而是一个围绕目标持续推进的执行系统。

和单轮生成不同，Agent 面向的是开放任务，这类任务通常信息不完整、路径不确定，而且需要借助外部反馈修正过程，所以不能指望一步生成最终答案。

在这个系统里，LLM 更像局部决策器，负责判断下一步该做什么；tool calling 则把模型的自由输出收敛成可执行、可治理的动作；planning 用来组织多步任务，降低局部决策的盲目性；workflow 提供边界、治理和稳定性，Agent 则处理其中不确定的决策节点。

所以对于Agent，重点不仅仅在 prompt，还在目标、动作、状态、反馈和控制。

额外思考

第一，系统服务的是“回答一个问题”，还是“完成一个目标”？

如果只是回答问题，那大概率还在生成系统范式里。

第二，模型负责的是“写最终文本”，还是“决定下一步动作”？

如果模型只输出内容、不承担过程决策，那 Agent 味道就很弱。

第三，tool 是偶发增强，还是执行闭环的一部分？

真正的 Agent 会把工具结果写回状态，再影响后续决策，而不是“偶尔调用一下 API”。

第四，系统有没有明确边界和终止条件？

如果没有 max steps、没有超时、没有失败策略，那本质上不是执行系统，而是一个容易失控的生成循环。