先明确业务成功条件，再决定哪些步骤交给模型、哪些步骤留给确定性代码。
本文于 2026-09-12 补充整理，按 2026-03 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
先把“成功”写成业务条件
假设要做一个企业知识库与工单助手：员工查询部署规范，系统返回带出处的解释；仍不能解决时，助手整理环境、现象和排查记录，经过确认后创建工单。这个场景足够小，却同时包含检索、推理、读接口和写接口，适合观察 Agent 的工程边界。
问答成功要求结论有可访问的依据；创建工单成功要求业务系统确实返回了工单编号。模型说“已完成”，不能替代任何一项验收。对缺少环境、错误码的问题，正确行为可能是追问，而不是立即检索或创建工单。
Anthropic 对 workflow 与 agent 的区分着眼于执行路径由代码预先确定，还是由模型动态选择。下面的边界划分是针对这个示例的设计建议。
三种路径分别承担什么
| 请求 | 建议路径 | 原因 |
|---|---|---|
| 已知编号查工单状态 | 固定服务调用 | 参数明确，动态规划没有明显收益 |
| 查询发布失败的处理办法 | 检索增强问答 | 需要内部证据，但执行链基本固定 |
| 综合现象定位问题并准备工单 | 有预算的 Agent 循环 | 后续动作依赖中间结果 |
不应让所有请求都经过同一套自主循环。即使一个入口面向用户表现为“助手”，内部也可以由路由器选择不同执行方式。路由结果若不明确，就进入澄清状态；不能把低置信度自动等同于“交给更多 Agent”。
建议的数据流如下：
请求 → 身份和配额 → 意图路由
├─ 固定查询 → 结果校验
├─ RAG → 引用校验
└─ Agent → 受控工具 → 任务状态
↓
待确认命令 → 工单服务
Java 服务应持有业务权力
模型负责提出动作建议。Java 应用负责执行参数校验、权限判断、预算检查和业务状态转换。租户、当前用户、可访问项目从认证上下文获得，不能允许模型通过参数任意指定。
可以把核心组件划为四个模块：任务应用服务管理生命周期；知识模块生成证据；工具适配器连接已有 API；模型适配器处理供应商差异。初期放在一个进程中，通过接口隔离即可。没有独立扩缩容、团队边界或故障隔离需求时，拆成多个微服务只会增加排查成本。
业务层可定义自己的 TaskId、Evidence 和 ProposedCommand。框架返回的消息对象留在模型适配层，避免数据库中充满某个 SDK 的内部类型。
给自主程度设置上限
假设单个任务最多允许 6 次模型调用、3 次检索和 1 个待审批写操作；这些数字只是初始实验参数。超限后任务应保存当前证据和停止原因，返回可理解的部分结果。没有证据时不能靠增加轮次无限尝试。
停止原因至少区分：成功、需要用户补充、等待审批、预算耗尽、依赖失败。一个统一的“系统异常”会把正常澄清和真正故障混在一起，也无法支持后续评测。
怎样证明这个边界合理
准备三类输入：准确工单编号、明确知识问题、缺少信息的排障请求。记录路由、实际工具调用和任务终态。再让同一组输入全部进入 Agent 循环，比较任务正确率、模型调用次数和端到端耗时。
这里的关键证据是：固定查询是否产生多余模型调用；缺信息时是否正确追问；写操作是否一定经过命令校验和确认。只有自主路径在这些约束下提供了额外价值，增加复杂度才有依据。
面试中解释这套方案，可以从“哪些决策必须确定”开始，再说明模型在哪些信息不完整的步骤提供帮助。这比从框架组件列表开始，更容易体现架构判断。
