本文目录#

引言：为什么“看起来能跑”不足以上线#

在 Agent 项目里，最容易出现的错觉是：

本地演示通过了，说明可以上线。

现实往往相反：演示关注的是“能不能工作”，上线关注的是“在波动条件下能否持续工作”。

这篇我们解决的是第二个问题：如何把评估（Eval）、回归（Regression）、风险控制（Safety/Cost）整合成可执行上线闸门。

1. 先定义一套“统一评分板”#

如果每个团队各自定义成功标准，最终会出现“都说自己通过了，但生产表现仍然不稳定”。

对一线工程师最实用的是四维评分板：

  1. 正确性：回答是否满足需求，是否引用了正确上下文。
  2. 稳定性：同类输入多次运行，结果波动是否可接受。
  3. 成本：单请求 token、工具调用次数、总成本是否在预算内。
  4. 风险：越权调用、敏感信息泄露、错误自动执行是否被拦截。

建议先定“红线阈值”，再谈优化目标。

示例（仅示意）：

1
2
3
4
5
正确性 >= 90%
关键场景失败率 <= 2%
p95 延迟 <= 3s
单请求成本 <= 目标预算上限
高风险误执行 = 0

2. 回归测试分层：单步、流程、端到端#

很多团队只做一种测试，导致覆盖盲区。更稳妥的方式是三层并行：

2.1 单步测试（Step-level）#

验证 Prompt 模板、检索召回、工具参数映射等局部逻辑。

2.2 流程测试（Workflow-level）#

验证多步骤协作：计划 -> 调工具 -> 汇总 -> 输出。

2.3 端到端测试（E2E）#

模拟真实请求，验证完整链路在真实依赖下是否稳定。

可执行原则：

  • 单步测试负责“快反馈”；
  • 流程测试负责“防协作断层”；
  • E2E 负责“上线前真实风险确认”。

3. 把“先失败”变成团队硬门禁#

Agentic Engineering 的关键不是“测试多”，而是“测试先”。

在上线相关开发中，建议固定门禁顺序：

1
2
3
4
5
6
7
(1) Baseline 绿
(2) 新增/修改测试
(3) 首次失败证据
(4) 最小实现
(5) 受影响测试 + 全量验证
(6) 连续两轮通过
(7) 才允许进入发布

这套顺序的意义在于：

  • 避免“先写再补测试”的回忆式验证；
  • 避免“偶发通过”被误判为稳定；
  • 避免“修功能时顺手削弱测试资产”。

4. 成本与安全必须并入同一闸门#

很多团队把成本和安全放到“后续治理”。这是高风险做法。

4.1 成本闸门#

至少要做三件事：

  • 请求级预算上限（max tokens / max latency）；
  • 会话级预算告警（超过阈值触发降级）；
  • 发布级预算评估（新版本相比旧版本不可出现不可解释上涨）。

4.2 安全闸门#

至少覆盖四类检查：

  • 权限不足时是否能正确拒绝；
  • Prompt 注入输入是否触发防护；
  • 敏感字段是否被脱敏；
  • 高风险工具调用是否有审批/二次确认。

对一线工程师最重要的是：把“不可接受风险”写成可执行断言，而不是写成口号。

5. 发布闸门模板（可直接复用）#

1
2
3
4
5
6
7
8
9
10
发布前必须满足：
- Baseline: 通过
- 新需求测试：已新增
- 首次失败证据：已留存
- 修复后验证：受影响测试通过
- 全量验证：通过
- 双轮一致性：通过
- 成本阈值：通过
- 安全阈值：通过
- 回滚预案：已验证

配套角色建议：

  • 开发：提交变更与自测证据；
  • 评审：核对门禁是否完整；
  • 发布责任人：确认闸门通过并执行灰度；
  • 值班：观察关键指标并准备快速回退。

6. 常见反模式与纠偏#

反模式 1：只看正确率，不看波动#

纠偏：引入“重复运行一致性”指标。

反模式 2：只做功能回归，不做预算回归#

纠偏：把成本变化纳入发布对比表。

反模式 3：安全规则只在网关做，不在测试做#

纠偏：把高风险场景做成固定回归用例。

反模式 4：把门禁当阻力#

纠偏：把门禁结果可视化，证明其在减少事故和返工。

结语：没有闸门的速度，不是工程速度#

Agentic Engineering 的质量核心，是把“上线前的侥幸”替换成“上线前的证据”。

下一篇（Part 3）我们进入最后一块：上线后的可观测、回滚与复盘机制，如何决定这套流程能否长期稳定运行。

本作品系原创，采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，转载请注明出处。