概念/概念定义
执行型 Agent 不是内容生成型 Agent：先把场景归类
出自东方屹腾执行型 Agent 落地（案例提供 梁博）
概念定义
设计一个 Agent 之前，先要回答一个比技术更靠前的问题：它要交付的是内容，还是执行。这个分类决定了后面整套架构的取舍走向。
内容生成型 Agent 以产出为主，工具之间松散编排，参数可以由 LLM 当场合成。投研报告、旅行助手、写 PPT 都属于这一类：先并行查资料、再总结、再喂给报告生成、再接一道评审质检，每一步传递的主要是文本内容，没有严格的机械状态绑定关系。执行型 Agent 不一样，它以用户的业务意图为输入，通过一连串业务 API 的可靠编排调用，自动交付完整的业务流程。它重交付，不重生成；步骤之间有严格的先后依赖，传递的是 id、状态码、实体引用这类机械参数，顺序错一步或参数错一位就会交付失败。
两类的区别，可以用抽卡来对照。内容生成型 Agent 有 second chance：抽到不满意的一张，再生成一张就是了，重试几乎没有代价，这是它能容忍 LLM 漂移的根本。执行型 Agent 没有这种容错——一旦误操作了业务数据，没有重来。容错能力的差异，决定了两类在可靠性上的设计要求不同。
使用说明
它防住的，是把执行当成内容来做的那个具体失败。在 MCP 协议里，Agent 作为 Client 只感知工具、调用工具、把结果以文本塞回上下文，参数的理解和生成全部交给 LLM。这套设计在通用助手场景里价值极大，用到执行型场景却会出问题。东方屹腾团队最早的判断和很多 SaaS 公司一样：把原有 API 按 MCP 实现成 Server，是不是就能让机器人自动跑完业务流程。真拿几个核心场景去落地，立刻走不通——走不通的原因恰恰是 MCP 的开放和灵活。LLM 是概率模型，生成总会漂移，加再多 JSON-Schema 约束、换再强的模型，都有出错和幻觉的时候。团队要的是确定的执行结果，确定就不能只靠概率，这与 MCP 把参数生成交给 LLM 的前提直接冲突。
东方屹腾是一家做企业人事、组织、考勤、审批、薪酬的 SaaS 公司。开场那个报销的例子把这道坎说得最清楚：在费控系统里报销是「先创建申请、再上传发票、再提交审批、再查询结果」，上传发票时绑定的申请 id 必须是上一步业务系统刚返回的那个，不能是任意 id，更不能让模型自己生成一个。人在 GUI 上做这件事毫无难度，因为每个按钮调哪个方法、绑什么参数，程序早就钉死了。交给 Agent 自动做，这些显式操作没了，调哪个工具、准备什么参数全由它负责。团队踩过这个坑：把每步结果像 tool_call 一样追加到上下文，让模型从上下文里解析绑定下一步参数，实测下来极度不可靠，有时成功有时失败，什么时候失败既不可控也无法预料。这之后，团队把自己要做的明确归为执行型，整套架构后续所有取舍，都从这条分野开始。
何时需要
当你的 Agent 在执行一连串有严格状态依赖的业务流程，而且参数错一位会破坏业务数据或产生「假成功」，那就是执行型，得按执行型的重机制来设计。划清了类别之后，控制和叙事怎么分，见控制平面与叙事平面的二元论；执行型最核心的那个机械参数问题怎么解，见机械状态平面与 Provenance 坐标。