很多人第一次做 Agent 都会经历同一条路径：
- Demo 很惊艳
- 一上线就开始“偶尔很好、偶尔发疯”
原因通常不是模型不够强，而是缺少工程化要素：状态、约束、回放、观测、失败恢复。
这篇文章把我认为最关键的 7 点整理成一份“上线前检查表”。
1) 明确 Agent 的边界：它到底能做什么，不能做什么
先写一段非常具体的“职责说明”（类似产品 PRD 的一句话版本）：
- 输入范围：用户问题、已有上下文
- 输出范围：文本答复/结构化 JSON/创建任务
- 禁止事项：涉及资金、删除数据、外发内容必须人工确认
边界越清晰，越容易做护栏和测试。
2) 工具调用要“可验证”：宁可少，也别玄学
工具调用（function calling / tool use）要做到两件事：
- 参数可校验（schema + 业务校验）
- 结果可复用（工具输出结构化，别是长段自然语言）
常见错误：工具返回一大段文本，模型再总结一次 → 误解 + 幻觉概率翻倍。
3) 状态管理：不要把一切都塞进 prompt
你需要区分三种状态：
- 短期对话上下文（最近几轮）
- 任务状态（步骤 3/7、已完成哪些）
- 长期记忆（偏好、固定资料）
工程里更靠谱的做法是：
- 任务状态用结构化对象保存（JSON/DB）
- 只把“必要摘要”注入 prompt
4) 计划（Plan）要轻量：可执行比好看重要
很多 Agent 失败在“计划很宏大但无法执行”。
建议：
- 计划最多 3~7 步
- 每一步都要能映射到工具/动作
- 每步输出都有明确的验收条件
如果做不到，说明任务需要拆分或需要更多信息。
5) 护栏（Guardrails）：别只靠“请你谨慎”
护栏最好是多层的：
- 前置拦截：敏感意图识别（删库/转账/外发）→ 直接要求确认
- 参数拦截：危险参数（
rm -rf、高权限操作）直接拒绝 - 后置检查：输出是否包含隐私、是否引用了不存在的来源
最有效的一招：对外部副作用操作必须二次确认（human-in-the-loop）。
6) 可回放（Replay）：能复现才能修
上线后用户会说：
“刚才它明明说可以，现在又不行了”
如果你没有回放能力，就只能猜。
至少记录：
- 用户输入
- Agent 当时看到的上下文摘要
- 工具调用序列（含参数、结果、耗时）
- 最终输出
有了回放，你才能做“失败样本集”，然后针对性修。
7) 评测：用真实任务做回归
Agent 的评测不要只看“答得像不像”。
更应该看：
- 工具调用成功率
- 任务完成率（端到端）
- 平均步骤数（越少越好）
- 人工介入次数
做一个最小回归集（比如 30 条真实任务），每次改 prompt/策略/模型都跑一遍。
结语
Agent 不是“更复杂的聊天”，而是一个会产生行为的系统。
如果你把它当软件工程来做：
- 有状态
- 有护栏
- 有回放
- 有评测
它的稳定性会比你想象中提升得快。