本文目录#

引言：真正决定成败的是上线后的 72 小时#

很多团队把大量精力放在“上线那一刻”，却忽略了上线后的运行现实：

  • 用户输入分布和测试集不同；
  • 上游依赖波动比预期更大；
  • 成本和延迟在高峰时段出现结构性变化；
  • 小概率故障在规模下会变成高频事件。

Agentic Engineering 的闭环必须覆盖三件事：可观测、可回滚、可复盘。没有这三项，前面的需求、设计、闸门都会慢慢失效。

1. 可观测：你需要的不是“日志很多”，而是“问题可定位”#

建议把观测对象分成四层：

  1. 任务层：一次用户请求是否成功，失败属于哪类。
  2. 推理层：模型调用耗时、token、重试、拒答。
  3. 工具层：每个工具调用成功率、耗时、错误码、幂等冲突。
  4. 业务层：转化、留存、人工接管率、投诉率。

如果只看模型层指标，你会误判很多问题。例如模型成功返回了，但工具执行失败，业务结果仍然失败。

建议最小观测字段：

1
trace_id / request_id / tenant / use_case / model / tool / latency / tokens / cost / error_class

2. 预设告警：先定义“何时拉闸”，再等告警响起#

告警不是为了“发现有问题”，而是为了“触发动作”。

一线团队可先定义三档阈值：

  • P1（立即回滚）：关键路径错误率暴涨、越权执行、敏感数据泄漏；
  • P2（降级运行）：延迟超阈值、成本异常上升、上游限流持续；
  • P3（观察与优化）：非关键功能抖动、次要工具失败率上升。

对应动作必须提前写好：

1
2
3
P1 -> 立即切回旧版本 + 通知值班 + 冻结新发布
P2 -> 降级模型/关闭高成本路径 + 持续观测
P3 -> 建问题单并进入下个迭代修复

3. 回滚：回滚能力不是开关，而是演练出来的#

很多系统“理论可回滚”，但故障时回不去。原因通常有三类：

  1. 回滚路径依赖了已经变更的数据结构；
  2. 发布时没有保留旧配置与旧模型路由；
  3. 团队缺少实战演练，故障时操作顺序混乱。

建议每个迭代至少做一次小型演练：

  • 模拟上游超时；
  • 模拟模型输出异常；
  • 模拟工具权限错误；
  • 验证是否能在目标时间内恢复。

并把目标时间写死，例如：

  • 5 分钟内完成流量切换；
  • 15 分钟内恢复核心链路；
  • 30 分钟内给出对内事故通报。

4. 复盘：复盘不是追责会，而是系统改进会#

高质量复盘必须回答 5 个问题：

  1. 触发条件是什么？
  2. 哪条门禁本应拦截但没拦住？
  3. 观测信号为何没及时触发？
  4. 回滚为什么快/慢？
  5. 下次如何通过机制避免同类事故？

建议用“机制导向”结构写复盘：

1
事实时间线 -> 决策点 -> 失效门禁 -> 补强动作 -> 负责人与截止时间

只有当复盘结果沉淀进门禁、测试、告警规则，复盘才算完成。

5. 组织协作：把“个人经验”固化成“团队默认流程”#

Agentic Engineering 成熟度的关键标志，不是某个工程师多强，而是新同事加入后也能在两周内按流程稳定交付。

建议在团队内固定三类资产：

  • 运行手册（Runbook）：故障时谁做什么、先后顺序是什么；
  • 门禁模板（Gate Template）：每次发布必须经过的验证项；
  • 复盘知识库（Postmortem KB）：同类问题历史、修复策略与禁忌操作。

这三类资产会显著降低“人员变动导致质量波动”的风险。

6. 连载总收束：从“写得快”走向“交付稳”#

回看三篇连载：

  • Part 1 解决“如何把需求到发布流程化”；
  • Part 2 解决“如何把评估与闸门制度化”；
  • Part 3 解决“如何把运行与复盘长期化”。

这就是 Agentic Engineering 对一线工程师真正有价值的地方：
不是替你做决策，而是把你的决策转化成可执行、可验证、可复用的工程系统。

如果你准备在团队里落地，建议从最小闭环开始：

  1. 先定义一条核心链路；
  2. 先接入一套最小观测字段；
  3. 先建立一份发布闸门模板；
  4. 先完成一次故障回滚演练。

当这四件事稳定后，再扩到更多 Agent 场景，成功率会高很多。

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