本文目录
AI Agent 是能够围绕目标多次观察、决策和调用工具的系统。它与单次模型请求的区别，不在于提示词更长，而在于程序允许模型根据工具结果选择下一步，直到完成、失败或触发停止条件。
Agent 带来更强执行能力，也放大错误累积、权限越界和成本失控的风险。可靠设计的重点不是让它“尽可能自主”，而是让每一步都受任务契约、工具边界和运行时策略约束。
先判断是否真的需要 Agent#
固定输入经过固定步骤得到结果，优先使用普通代码或工作流。只有当中间路径需要根据观察动态选择，并且工具结果会影响后续行动时，Agent 才有明显价值。
适合 Agent 的任务包括：
- 根据报错和代码动态定位缺陷
- 从多个数据源收集证据并形成调查结论
- 按工单内容选择不同处理工具
- 在测试失败后决定修复、回退或请求人工帮助
支付扣款、固定审批流、确定性数据转换和严格顺序迁移通常更适合状态机。能用确定流程解决的问题，不要用开放式循环增加不确定性。
用任务契约约束目标#
Agent 启动前应获得可检查的任务契约，而不是一句“处理这个问题”。至少包含：
- 目标：最终需要产生什么结果
- 输入：允许使用的数据和初始上下文
- 权限：可以读取、写入和调用哪些系统
- 成功条件：怎样判断任务完成
- 失败条件：哪些情况必须终止或转人工
- 预算：最大步骤、时间、调用和费用
“处理所有告警”过于宽泛；“分析指定告警，读取最近 30 分钟日志，给出根因候选和证据，不允许重启服务或修改生产配置”才有可控边界。
Agent 的基本执行循环#
读取任务和当前状态
↓
选择下一步动作
↓
策略层检查权限与预算
↓
执行工具并记录结果
↓
更新状态、判断完成或继续程序而不是模型负责循环控制。运行时应在每轮检查预算、重复动作、取消信号和人工审批，不能依赖模型主动停止。
while not finished:
if budget_exceeded or cancelled:
stop
action = model.decide(task, state, available_tools)
decision = policy.check(action)
if decision requires approval:
wait_for_human
observation = execute(action)
state = record(action, observation)
finished = evaluate_stop_conditions(state)模型提出动作，策略层决定是否允许，执行层调用真实系统，评估层判断是否结束。这些责任不应混在一个函数里。
工具决定能力边界#
工具不是对内部 API 的随意包装。一个可用工具需要明确：
- 名称和适用场景
- 结构化输入与字段约束
- 成功输出和错误类型
- 是否有副作用
- 超时、重试和幂等策略
- 所需权限和审批级别
“执行任意 SQL”或“运行任意 shell”很难审计。优先提供领域工具，例如 get_order_status、create_refund_request，并在服务端再次验证业务权限。
写操作要处理重复调用#
Agent 可能因超时、误判或任务恢复而重复调用工具。创建订单、发送通知和更新状态需要幂等键，或者先读取当前状态再执行目标状态转换。
不要把“模型应该记得刚才做过”当作一致性保障。真正的防重复必须存在于工具和下游系统中。
状态、上下文和长期记忆#
- 状态：任务当前事实，例如已执行步骤、工具结果和剩余预算
- 短期上下文：本轮提供给模型、用于下一步决策的信息
- 长期记忆：跨任务保存的偏好、知识或历史经验
状态应结构化并可恢复，不能只存在于聊天文本。短期上下文保留目标、最新证据和未解决问题。长期记忆写入前需要来源、有效期、权限和纠错机制，避免错误结论永久影响后续任务。
停止条件必须强制执行#
至少设计以下停止路径：
- 成功条件已经满足
- 达到最大步骤、时间或费用
- 同一工具连续失败
- 多次重复动作而没有新信息
- 缺少必要权限或关键输入
- 风险动作需要人工决定
- 用户取消或上游任务失效
停止不等于失败。信息不足时带着证据转人工，比继续猜测并消耗预算更可靠。
人工审批放在哪里#
审批应根据风险触发，而不是每一步都弹窗，也不是完全取消。通常需要确认的动作包括：
- 删除、覆盖或不可逆修改
- 向外部用户发送消息
- 涉及资金、合同或账号权限
- 修改生产配置或触发部署
- 读取超出任务范围的敏感数据
- Agent 无法判断的业务例外
审批界面应显示动作、参数、原因、预期影响和替代方案。只显示“是否允许工具调用”无法帮助用户有效判断。
用事件记录实现可观测性#
生产 Agent 需要能回答“为什么做了这一步”。建议记录：
- 任务 ID、版本和初始目标
- 每轮可用工具和选择结果
- 策略允许、拒绝或要求审批的原因
- 工具参数摘要、耗时、状态与错误分类
- token、调用次数和费用预算
- 最终结果、停止原因和人工反馈
日志要可追踪但不能保存明文密钥和不必要的个人数据。模型输入输出应按敏感级别脱敏、采样或限制保留时间。
用固定任务集评估#
几个成功演示无法证明可靠性。建立包含正常、边界、对抗和失败场景的评估集，并保存预期行为。
常用指标包括：
- 任务成功率和关键事实正确率
- 非法或越权工具调用率
- 平均工具调用次数与任务耗时
- 单任务成本和超预算比例
- 请求人工帮助的准确性
- 相同输入多次运行的一致性
评估不能只看最终答案。结果正确但过程中读取无关敏感数据或执行危险命令，也应判定失败。
工单分类 Agent 案例#
可以从低风险只读场景开始：分析新工单并建议分类，但不自动回复客户或修改状态。
目标：为指定工单建议类别、优先级和负责团队。
允许：读取工单正文、产品目录和公开故障公告。
禁止：查看其他客户数据、发送消息、修改工单。
输出：建议结果、引用证据、置信度和待确认问题。
停止：证据不足时转人工；最多调用 6 次工具；总时限 60 秒。工具可拆为 get_ticket、search_product_docs 和 list_public_incidents。评估集应包含信息完整、描述模糊、恶意指令、重复工单和涉及隐私的案例。
只读版本稳定后，再增加“保存分类建议”工具；自动发送回复应作为更晚、更高风险的阶段。
常见失败模式#
工具数量过多#
大量重叠工具增加选择错误。合并重复能力，并按任务只暴露必要工具。
错误进入长期记忆#
长期记忆需要来源和审核，不能把模型推断当成永久事实。
重试放大副作用#
网络失败不代表操作未执行。写工具必须支持幂等和操作状态查询。
只优化提示词#
权限、预算、停止和输入验证应由代码强制，不能依赖一句“不要做危险操作”。
评估只有成功路径#
加入工具超时、权限拒绝、冲突信息、提示注入和用户取消，才能发现真实风险。
上线前检查#
- 是否证明任务确实需要动态 Agent
- 任务契约和成功条件能否检查
- 工具是否最小化、结构化且服务端鉴权
- 写操作是否幂等并可审计
- 状态能否持久化、恢复和迁移
- 是否有步骤、时间和费用硬上限
- 高风险动作是否进入人工审批
- 日志是否可追踪且经过脱敏
- 评估集是否覆盖边界和对抗输入
- 是否具备暂停、取消、降级和回滚方案
从受控自动化开始#
可靠 Agent 通常从只读工具、有限步骤和建议模式开始。先让系统产生可审查结果，再逐步开放写权限和自动执行。
Agent 的工程目标不是模拟一个无所不能的人，而是在清晰任务中稳定调用有限工具，并在超出边界时及时停止。做到可控制、可观察、可评估，才适合进入生产流程。