当信号亮红灯：Agent 的排错能力

前面四节搭建了一个多层次的反馈体系：静态分析在毫秒内拦截类型问题，CI 在分钟内报告构建和测试结果，可观测性在小时到天的尺度上追踪运行时行为，IaC 保证这些反馈信号的可靠性。但反馈只是告诉你"出了问题"，不告诉你"为什么出了问题"。

排错是反馈体系的最后一环。当某一层的信号亮了红灯，Agent 需要能够定位问题的根因。这个能力的质量，决定了整个反馈体系能否真正闭环。

Agent 的排错能力在过去一年有了实质性的进展。实践中已经出现这样的场景：一个 bug 涉及数据库、缓存、前端、后端 API 和对象存储五个子系统，Agent 自主编写诊断脚本查询各系统的实际数据、与预期值比对、逐步缩小范围，在三十分钟内定位到根因。这大致等效于一个熟悉项目的中级工程师的排错能力。

但排错能力的上限取决于 Agent 能"看到"什么。这就是前面几层基础设施的价值所在。如果日志是结构化的、指标是有粒度的、链路追踪是完整的，Agent 有充足的信息去做推理。如果日志是散乱的文本、监控只有粗粒度的 dashboard、没有链路追踪，Agent 面对的就是一个几乎无法诊断的黑箱。

排错能力也对平台架构提出了要求。一个有意思的案例是：将 UI 和渲染层通过远程协议分离，产生可机器读取的 UI 状态快照。这个架构决策最初是出于其他目的做出的，但事后发现它让 Agent 能够"看到"复杂的 UI 状态，配合 debugger 技能诊断原本只有人类才能排查的视觉 bug。平台架构中哪些信息以机器可读的形式暴露，直接决定了 Agent 排错能力的天花板。

还有一个层面的变化值得注意。当工作流从人类写代码变成人类写规约、Agent 写代码，调试的对象也发生了跃迁。过去你调试的是代码：设断点、看变量、追踪执行路径。现在越来越多的时间花在调试指令上：修改 prompt、调整约束条件、优化上下文结构，直到 Agent 的输出能一次通过验收标准并直接合并。抽象层上升了，但核心的反馈循环（假设、测试、验证、修正）本质没变。

这也暗示了平台工程的一个延伸方向：不仅为 Agent 的代码产出建立反馈体系，也要为人类的指令产出建立反馈体系。如果一条指令导致 Agent 反复产出不合格的代码，平台应该能检测到这个模式并提示人类："这条指令可能需要修改"。反馈不只是从环境流向 Agent，也需要从 Agent 的行为模式流向操控 Agent 的人。