案例库/完整蓝皮书

证据边界：本文记录东方屹腾执行型 Agent 的项目实践。业务背景、原型问题和架构取舍由案例方梁博提供，尚未经过独立审计。示例数据结构由 ADPS 根据案例机制整理，用于解释设计，不代表案例方实际类名或字段名。

案例速览

1. 先找客户真正卡住的那一步

东方屹腾的 SaaS 产品覆盖人事、组织、考勤、审批和薪酬，并连接银行与税务系统。产品矩阵已服务两万多家企业。团队最初评估过用工分析、薪酬结构优化和报表分析，这些场景容易演示，却没有击中客户启用系统时最费力的环节。

客户访谈指向了首次配置。新企业需要建立薪资组和薪资项，导入员工与组织，完成定薪，再配置考勤和审批规则。由运营团队代为配置的客户通常能顺利启用，自行配置的客户更容易中途放弃。

团队把“薪资组快速搭建”定为首个场景。它的范围不大，却包含模板匹配、数据快照、连续 API 调用、失败回滚和人工确认。一个 Agent 若能稳定完成这条链，才有资格继续进入算薪、代发和报税。

2. 第一个原型：工具选对了，状态仍会传错

最初的设想很直接：把现有 API 封装为 MCP Server，让模型按用户意图选择工具并组织参数。工具发现很快跑通，连续调用暴露了另一个问题。

以报销为例，流程依次创建申请、上传发票、提交审批和查询结果。上传接口使用的 application_id 必须来自刚才那次创建调用。薪资组配置也一样，模板匹配返回的 template_id 要原样进入后续导入接口。

早期原型把每步回执追加到对话上下文，再让模型生成下一步参数。测试中出现过 ID 误写和参数错绑。JSON Schema 可以检查字段类型和格式，无法证明一个值来自哪次调用。对于 64 位或 128 位业务标识，只错一个字符也可能访问错误实体。

这次失败划出了一条系统边界。

• 报告、摘要和 PPT 在步骤间传递文本，局部偏差通常还能重写。
• 薪酬、审批和报销在步骤间传递业务状态，漏步、跨步和参数错绑会改变真实数据。

东方屹腾继续使用模型理解用户和选择业务路径，同时把严格参数从语言上下文中拿出来，交给程序保存和注入。

3. 先把运行过程看清楚

后端使用 Go，初期没有引入 Agent 框架。第一阶段只接通连续对话、附件上传和流式回复，先固定入口和输出协议。Web 界面同步建设，业务人员可以在同一页面检查用户输入、执行进度和最终结果。

运行时从第一天就记录结构化事件。一次对话拆成按时间排序的 Activity，每个 Activity 下包含一个或多个 Frame。Frame 保存当时的输入、模型输出、工具调用、耗时和费用。意图识别、路由、ReAct 循环和状态变化也写入同一时间线。

这套记录先解决开发问题：哪一步选错了工具，哪个 ID 来自哪次调用，任务为何停在审批节点。生产环境再按权限隐藏调试详情。可观测性在这里不是上线后的监控补丁，它是业务评审和问题复现的共同底座。

4. 一次请求怎样流过系统

用户输入先经过意图识别，得到有限的控制信号。早期信号包括 chat、analyze 和 resolve，解析失败则进入 unknown。后续类型可随业务扩展，但每个类型都必须对应明确的程序分支。

用户消息
  -> MessageHandler 接收并建立事件流
  -> 意图识别生成控制信号
  -> Orchestrator 选择执行链
  -> 推理或规划确定下一步
  -> 行动模块调用工具
  -> 状态、任务进度和叙事摘要分别落盘
  -> 统一事件流向界面返回进度与结果

MessageHandler 处理消息入口、SSE 和结束协议。Orchestrator 读取控制信号，调用推理、记忆、检索和行动模块。业务能力注册在明确的输入输出契约上，新增能力主要接入中段流程，不需要改动消息入口。

系统也把两类信息分开保存。控制信号、任务状态和准入结果驱动程序分支；用户目标、分析结论和执行摘要进入模型上下文。前者要求枚举和校验，后者允许语言表达。案例方把它们分别称为控制平面和叙事平面。

5. 什么时候探索，什么时候按计划执行

resolve 说明用户要完成一件事，还没有给出稳定步骤。任务边界模糊时，系统使用链式推理或 ReAct 边执行边判断。每轮把 Thought、Action 和 Observation 追加到 scratchpad，下一轮读取最新观察。

严格依赖出现后，控制权交给规划执行。规划器把任务拆成 DAG，执行器只调度所有上游节点已经完成的 ready 节点，验收器决定节点能否进入 completed。

薪资组快速搭建的模拟链包含模板匹配、现有数据快照、模板导入和失败回滚。它曾仅以文字步骤交给 ReAct，测试中出现跨步和漏步。任务图正是由这次失败推动出来的。

6. 业务 ID 由程序保管来源

工具回执中的严格参数进入 SessionState。后续工具按坐标读取，模型只看到“模板已经匹配”这类叙事摘要。每个状态值同时保存来源信息，调用前可以核对生产工具和调用实例。

下面是 ADPS 根据案例机制整理的示意结构。

{
  "scope": "session/payroll_setup",
  "key": "template_id",
  "value": "9287461350021",
  "producer": "match_salary_template",
  "call_id": "call_0187",
  "receipt_ref": "events/0187/tool-result"
}

工具注册时声明自己生产和消费哪些状态。RunPipeline 在调用前完成四件事：根据坐标取值，核对来源，注入参数，记录本次消费关系。模型不会再次拼写 template_id。

这套机制成立于封闭工具体系。组织需要事先管理工具注册、状态键、作用域和权限。开放网络中的任意工具无法自动获得同样的来源保证。

7. 审批要能停住，也要能从原处继续

敏感节点开始前，执行器将节点置为等待审批。人工批准后，系统重新读取持久化状态，校验任务与工具条件，再从原节点继续。拒绝或超时则进入明确的终止或改计划路径。

案例包含两种人机衔接。

• 下一轮继续：当前会话结束，用户之后输入“继续”或补充信息，系统从已保存目标和进度恢复。
• 执行中等待：会话运行仍存在，某个任务节点阻塞，审批事件到达后恢复。

第二种方式需要持久化 DAG、节点状态、审批结果和参数来源。一个确认弹窗并不能提供恢复能力，真正的断点位于任务状态机。

8. 长程状态分放三处

系统逐步形成三个状态平面，各自回答一个问题。

Anchor 保存原始目标，避免长任务反复摘要后偏离。Ledger 追加关键进展，Collection 在当前步骤选择必要记录。它们服务语义理解，不承担业务 ID 传递。

记忆再按使用距离分层：L1 服务当前步骤，L2 保存可追溯事实，L3 保存从多次任务中提炼的经验。L3 召回结果仍保留指向 L2 的来源 ID，需要核对时再加载原始记录。召回集中在首次推理、ReAct 首轮和任务规划等边界，不在每一步重复检索。

9. 当前证据能说明什么

后续公开材料最值得增加三类数据：严格流程的成功率与人工接管率，参数来源校验拦截的错误数，以及审批暂停后的恢复成功率。

10. 迁移时可以照着做的七步

1. 选择一条会修改真实业务状态的连续流程，不从开放问答开始。
2. 列出每一步的输入、输出、副作用、回滚方式和人工责任人。
3. 标记所有不能由模型重新生成的值，例如业务 ID、版本号、金额和权限范围。
4. 为每个严格值登记生产工具、消费工具、作用域和回执位置。
5. 把已知依赖写成任务图，由程序决定节点是否可执行。
6. 将高风险节点设为可持久化的等待状态，测试批准、拒绝、超时和重复事件。
7. 用统一时间线串起模型、工具、状态和任务事件，再开始扩大场景。

第一条流程跑稳后，再判断哪些任务需要 ReAct，哪些可以直接进入固定计划。这样能把探索能力留给开放部分，把确定性留给业务状态。

11. 何时不该照搬

这套设计适合步骤明确、状态依赖严格、错误会改变业务数据的执行型任务。工具需要由组织注册和管理，状态键与来源能够事先定义。

资料检索、总结和报告生成通常不需要完整 DAG、机械状态平面和审批恢复。一次性脚本也未必值得建设长期会话状态。若工具来自开放生态，或同一业务值存在多个并发写入者，还需要补充信任策略、事务、锁和冲突处理，本案例没有覆盖这些问题。

12. ADPS 对照

案例提供与引用

案例提供：梁博（Bo Liang），上海东方屹腾科技有限公司。

建议引用：ADPS、梁博，《东方屹腾执行型 Agent：让业务状态沿流程准确传递》，ADPS 企业 Agent 系统蓝皮书·案例报告 01，v0.4，2026。