Agent 控制边界
提出问题
很多团队第一次做 Agent 时，问题不是模型不够强，而是控制边界不清楚。
用户说“帮我处理这些客户”，Agent 到底可以查哪些系统、改哪些数据、最多执行多少步、遇到不确定是否能继续、什么时候必须让人确认？如果这些问题只写在 prompt 里，Agent 就会在真实业务压力下表现得忽近忽远：有时过度保守，有时越权执行。
控制边界的核心判断是：能用 Workflow 稳定表达的流程，就不要交给 Agent 自主控制；必须交给 Agent 的动态部分，也要放在明确的目标、工具、权限、预算和恢复边界里。
场景
看一个采购审批助手。
企业员工提交采购申请后，系统需要检查预算、供应商资质、历史合同、部门审批规则，并生成审批建议。低金额采购可以自动流转，高金额或异常供应商需要法务和财务确认。
用户输入可能是：
帮我处理今天所有待审批的采购申请。低风险的给出通过建议，高风险的标记原因并转给对应审批人。
这个流程有稳定部分，也有动态部分：
- 稳定部分：读取待审批列表、按金额分层、检查必填字段、写入审批建议、通知审批人。
- 动态部分：判断供应商异常原因、查找相关合同、解释风险、决定还需要补充哪些证据。
如果全部做成 Workflow，长尾异常会很难覆盖。如果全部交给 Agent，风险也很高：它可能跳过预算检查，误用供应商工具，或者把“建议通过”直接写成“审批通过”。
这个场景里，Agent 不应该拥有整个审批流程的控制权。更合理的设计是：Workflow 负责确定性流程，模型负责局部判断，Agent 只在证据路径不固定时进入受控查证模式。
分析问题
问题类型
控制边界要先拆清任务类型。
模型可以帮助理解复杂文本和解释风险，但不应该自由决定业务状态。程序应该控制流程、权限、状态和副作用。人工应该确认高金额、合规异常、供应商黑名单、合同变更和外部通知。
收益和成本判断
Workflow 的收益是稳定：
- 步骤清楚，状态可追踪。
- 每个节点的失败和重试容易设计。
- 权限、审批和审计符合企业流程。
- 成本和延迟可预测。
Agent 的收益是弹性：
- 能处理没有预先枚举的异常。
- 能根据工具结果动态选择下一步。
- 能减少人工查证资料的时间。
- 能在信息不足时提出补充证据路径。
Agent 的成本也更高：
- 需要定义目标边界和退出条件。
- 需要工具白名单、风险分级和确认机制。
- 需要执行预算、循环检测和日志回放。
- 需要评估 Agent 是否越界、误用工具或做无效探索。
因此，控制边界不是在 Workflow 和 Agent 之间二选一，而是决定：哪些部分必须确定性控制，哪些部分可以开放给模型动态探索。
列举方案
方案阶梯
可以按控制权逐步开放。
第一层是规则和表单。适合采购金额分层、必填字段校验、部门审批链路。
第二层是 prompt 节点。模型只生成风险说明或审批建议，不改变系统状态。
第三层是 Workflow + Schema。模型输出结构化字段，由工作流校验后进入下一步。
第四层是 Workflow + Tool Calling。流程固定，模型或程序在固定节点读取预算、供应商和合同信息。
第五层是受控 Agent 子任务。只在“证据不足”或“异常复杂”时，让 Agent 在有限工具内查证，并返回证据包。
第六层是 Agent 编排。适合更复杂的研究、排障或代码任务，但仍要拆分 planner、executor 和 reviewer。
第七层是自治 Agent。只有在低风险沙盒、内部实验、强权限隔离和完整回放 eval 下才考虑。
什么时候简单 Workflow 足够
以下情况使用 Workflow 更合适：
- 流程步骤和分支可以提前列清楚。
- 每一步输入输出稳定，可以写 schema。
- 工具调用固定，例如每个申请都必须查预算和供应商。
- 失败处理清楚，例如缺字段就退回申请人。
- 业务要求强审计和强审批。
- 自动化目标是提速，而不是处理开放探索任务。
采购审批中，金额分层、预算检查、审批人匹配、通知发送都应由 Workflow 控制。模型可以提供解释，但不应该临时决定跳过这些节点。
什么时候需要 Agent 工程
以下情况可以引入受控 Agent：
- 异常原因无法用固定规则覆盖。
- 不同申请需要查询不同证据源。
- 工具返回结果可能改变后续查证路径。
- 人工当前瓶颈是探索和整合资料，而不是点按钮。
- Agent 输出只是证据包或建议，不直接完成高风险审批。
- 系统能限制工具、步数、数据范围和执行时间。
例如供应商被标记为“潜在关联方”，Agent 可以动态查询历史合同、相似供应商、过往审批备注和公开资质摘要，最后输出“证据和建议”，交给审批人确认。
控制边界设计
控制边界至少包含五层。
这些边界应该由运行时执行，而不是只出现在系统提示词里。
决策判断
方案选型表
反模式
第一种反模式：让 Agent 拥有整条业务链路。
采购审批、退款、权限变更这类流程有明确责任链。Agent 可以辅助查证和生成建议，但不应该临时决定业务状态如何流转。
第二种反模式：工具越多越好。
工具越多，误选和误用概率越高。Agent 的工具集应该按任务最小化，而不是把后台 API 全部暴露出来。
第三种反模式：把“建议”和“执行”混在一起。
approve_purchase 和 draft_approval_reason 是两个完全不同风险等级的能力。混在一个工具里会让确认、审计和回滚失去边界。
第四种反模式：没有退出条件。
如果 Agent 不知道什么时候证据足够、什么时候应该停止、什么时候转人工，就会过度探索或循环。
第五种反模式：用 Agent 弥补流程设计不清。
如果团队自己说不清审批规则、责任边界和失败处理，Agent 只会把混乱自动化。
第六种反模式：人工确认界面只显示最终结论。
审批人需要看到 Agent 查了哪些证据、哪些工具失败、哪些结论只是推测。只显示“建议通过”会制造虚假的确定性。
工程清单
- 场景边界：这个任务是否真的需要动态探索。
- Workflow 判断：哪些步骤可以用状态机稳定表达。
- Agent 子任务：Agent 的目标、输入、输出和完成条件是否结构化。
- 工具分级：查询、写入、高风险工具是否分开。
- 最小权限：Agent 是否只拿到当前子任务需要的工具和数据。
- 执行预算：步数、时间、token、费用和工具调用是否有限制。
- 数据权限：检索和工具层是否完成租户、角色、字段过滤。
- 人工确认：哪些动作必须确认，确认界面是否展示证据和风险。
- 审计日志：目标、计划、工具、参数、结果和确认人是否留痕。
- 失败处理：预算耗尽、证据不足、工具失败时是否能转人工。
- Eval：是否评估越界、误用工具、过度探索和错误建议。
- 回滚恢复：写入动作是否可撤销，任务是否能从断点继续。
结论收束
Workflow 和 Agent 的区别不在于“一个笨、一个聪明”，而在于控制权放在哪里。
稳定流程应该交给 Workflow，因为它可预测、可恢复、可审计。动态探索可以交给 Agent，但必须限制目标、工具、数据、预算和副作用。
好的 Agent 控制边界，是让模型在需要判断的地方发挥作用，同时让系统继续掌握流程、权限和责任。