本文要解决什么？
AI Agent 能调用工具，并不意味着它应该直接发送邮件、修改客户资料或提交正式结论。真正的工程难点在于让每一步可授权、可追溯、可中止。
从任务边界开始，而不是先选模型
“帮我开发客户”不是一条可直接验收的工作流。应拆成候选企业发现、企业身份核对、联系方式来源、线索入库、开发信草稿、人工批准发送，以及回复后的跟进等多个步骤。每步都应明确输入、输出、数据来源和是否允许副作用。
模型可以负责归纳与提出建议，但它不是企业权限系统，也不能代替最终的销售判断。高风险动作需要确定的审批人、审批范围和可撤回机制。
最小权限：读数据、写草稿和外发必须分级
推荐把只读检索、内部信息更新、生成待审草稿、对外发送等权限分开。拿到网页搜索权限不代表有权批量给陌生客户发邮件；能生成报价文本也不意味着可以直接修改 CRM 中的正式价格。
- 只读：搜索、读取获准使用的业务数据。
- 草稿：生成内容、提出修改建议，不触发外部动作。
- 内部写入：按对象、字段、用户角色和操作频率授权。
- 外部发送或不可逆操作：人工批准，记录批准的具体载荷和接收对象。
证据校验与裁决不应散落在多个模块
如果搜索模块、模型输出模块和报告模块都可以各自决定“资料已核实”，会出现重复裁决：某个模块说 PASS，另一个模块仍把没有出处的文字写入正式结果。更稳妥的设计是让一个经过验证的证据结果供下游消费。
下游模块可以格式化、展示、排序，但不能悄悄把未核事实升级为正式结论。模型响应中的来源说明应能追溯至原始文件、网页或人工确认记录。
副作用必须支持幂等和失败恢复
Agent 在 429、超时或网络断开后自动重试，如果每次都重新发一封邮件或创建一条客户记录，就会把技术故障变成业务事故。给具有副作用的动作绑定幂等键、执行记录与明确的完成状态。
恢复策略应该基于动作级别决定：可重试的读取任务可以自动恢复；已经产生外部影响但结果未知时，应先查询最终状态，不能盲目重试。
任务提出 → 权限检查 → 来源核验 → 草稿
↓
人工审核（审批的对象、内容和范围）
↓
执行动作（幂等键 + 审计日志）
↓
回执核验 → 成功 / 需人工处理 / 可安全重试验收看真实结果，不看 Agent 自报成功
工程验收应同时包含接口运行、浏览器操作、数据一致性和用户可看到的结果。只有模型返回“执行成功”，但 CRM 没有记录、邮件没送出或目标页面打不开，不应算通过。
上线前用真实权限和受控数据做端到端测试，并留下可复现的失败样本。能否处理异常，通常比一次演示是否流畅更能体现系统成熟度。
- 身份权限与审批记录真实可追踪。
- 副作用接口有幂等和可查询回执。
- 失败后没有重复发送、重复入库或隐蔽自动裁决。
- 业务人员能理解结果、限制和下一步操作。