可验证的结果为什么要自动验证？
- 原则: 如果操作结果可以被验证，就应该自动验证;
- 例子: Agent 调用
write_file 创建或修改代码时，工具不应只写入内容并返回“成功”，而应在写入后立即执行语法检查;
- 实现: 根据文件类型调用相应的 linter（代码静态检查工具），把输出解析为结构化的错误列表，作为工具返回值的一部分;
- 闭环: 代码有语法错误时，Agent 在下一轮思考中就会看到具体错误（如“第 10 行：未定义的变量
result”），从而可以立即修正;
长输出如何截断与持久化？
- 触发: 检测到输出超过阈值（如 200 行或 10000 个字符）;
- 做法: 只把头尾各若干行写入上下文，完整结果保存到临时文件;
- 头部保留: 前 50 行，通常包含初始输出或错误上下文;
- 尾部保留: 后 50 行，通常包含最终错误信息或成功标志;
- 中间提示: 如“
... [省略 8523 行，完整输出已保存至 /tmp/execution_output.txt] ...”;
- 文件引导: “如需完整输出，请使用
read_file 工具读取该文件”;
可观测性要提供什么？
- 目的: 监控、审计和调试 Agent 的执行行为;
- 日志: 每次调用的时间、参数、结果、耗时;
- 审计追踪: 谁在什么上下文下为什么执行了操作;
- 性能指标: 调用频率、成功率、平均耗时;
- 告警: 频繁失败、超时、资源超限时通知管理员;
取消或超时时副作用如何确定？
- 问题: 执行工具改变外部世界，因此必须回答——一次调用被取消或超时时，它的副作用到底发生了没有;
- 反例: 一个转账调用在网络超时后返回失败，钱可能已经转出，也可能还没转；Agent 若不加判断地重试，就可能重复转账;
- 核心概念: 幂等性——同一个操作执行一次和执行多次，对外部世界的影响完全相同，因而可以安全重试;
幂等性有哪两种实现手段？
- 唯一标识: 让操作携带唯一标识，服务端凭此去重，重复请求直接返回首次结果而非再次执行;
- 先查询后变更: 重试前先查询目标资源的当前状态（订单是否已创建、文件是否已写入），确认未完成再执行;
- 收益: 具备幂等性的操作让超时与打断的处理简单得多;
不可逆操作应如何两段式处理？
- 不可幂等的例子: 发送邮件、拨打电话、对外转账——每执行一次就产生一个不可撤销的真实世界事件;
- 预检-确认两段式: 第一段使用一个来自不同模型家族的模型和专用安全检查提示词做校验（检查余额、确认收款方、生成待发送内容），第二段才真正执行;
- 失败处理: 执行阶段如果失败不能盲目重试，而要把详细的错误信息返回给 Agent 主模型重新规划;