系统边界
Agent 系统的关键不是把模型包进一个聊天框，而是把任务拆解、工具调用、状态记录和失败回放变成一条可检查的执行链。
如果系统只保留最终回答，团队就很难解释一次失败来自模型判断、工具返回、上下文污染还是任务拆解本身。可观察性不是上线后的补丁，而是 Agent 设计的第一层边界。
上线问题
真正上线前，我会先问四个问题：任务是否能被拆成稳定步骤，工具调用是否可重放，失败样本是否被收集，评估是否能解释改动带来的影响。
Artifact
Agent 上线前检查清单
- 任务边界系统能说明哪些任务可执行、哪些必须拒绝或转人工。
- 工具权限每个工具调用都有权限范围、输入约束和失败处理。
- 状态记录关键步骤、上下文、工具返回和中间判断可追踪。
- 失败回放线上失败样本能被复现、标注和用于回归评估。
- 人工兜底高风险动作、连续失败和不确定输出能被人接管。
这些问题会迫使设计从演示脚本回到工程事实：输入是否可控，状态是否可追踪，工具权限是否收敛，异常是否能被人工接管。只要其中一项含糊，系统就还停留在原型阶段。
评估闭环
当这些问题有了答案，Agent 才不只是演示，而是一个团队可以维护、调试和持续改进的工程系统。
我更倾向把评估做成日常流程：保留失败回放，标注失败类型，把修复前后的样本结果放在同一个面板里比较。这样每次优化都能留下证据，而不是依赖一次漂亮的现场表现。