最近用ChatGPT、Codex处理真实项目时我越来越明显地感觉到一个变化Agent越能自己修问题系统就越需要把“发生了什么”说清楚。以前开发者排查问题很多时候靠的是经验。接口报错了。先看日志。感觉像数据库问题就去查数据库。感觉像缓存问题就清缓存。实在不行再一点点加日志、打断点、复现。整个过程中人会不断根据经验补全系统里缺失的信息。但Agent不一样。如果你只给它一句500 Internal Server Error它其实什么都不知道。它不知道错误发生在哪一层。前面经过了哪些步骤。哪个依赖变慢。哪个数据库查询异常。输入是什么。状态是什么。这个错误第一次出现是什么时候。于是Agent虽然很能写代码却只能开始猜。可如果同一个问题同时有Trace。Metrics。结构化日志。请求ID。错误栈。数据库耗时。上下游调用状态。那情况就完全不同。Agent不再只是“猜哪里可能有问题”。而是可以沿着证据链逐步缩小范围。所以我越来越觉得Agent时代可观测性不只是给人排错的工具。它开始变成Agent的“感知系统”。一、以前为什么系统“看不清”人也能勉强修因为人会补上下文。比如日志只写一句request failed有经验的开发者会马上问哪个请求哪个用户哪个服务发生在什么时间前后还有什么日志然后自己去grep。查数据库。翻监控。问同事。拼接出完整现场。也就是说系统本身提供的信息可能不完整。但人能够通过经验不断补齐。可Agent要真正独立处理问题就不能长期依赖这种方式。因为如果每遇到一步都要回来问人“这个错误对应哪个服务”“数据库日志在哪里”“有没有Trace ID”那Agent虽然能执行很多步骤却仍然无法真正自治。所以Agent自主程度越高对机器可读Evidence的要求反而越高。二、一个很真实的场景同样一个500错误Agent可能走两条完全不同的路假设线上出现POST /orders 500 Internal Server Error如果你只把这句信息交给Codex。它可能会开始读Controller。检查参数。看Service。分析数据库代码。甚至怀疑最近一次Commit。它有很多可能方向。但如果系统同时告诉它request_id: abc123 controller: 12ms service: 18ms database: 4920ms db_error: lock wait timeout query: UPDATE inventory...这时候问题已经完全不同。Agent马上知道Controller不是重点。Service也不是。真正异常集中在数据库锁等待。它接下来就可以继续分析哪个事务持锁。锁范围多大。有没有长事务。是不是并发更新同一行。也就是说同样的模型能力在不同可观测性条件下实际排障能力可能差很多。三、为什么这不是“日志多写一点”这么简单很多人一说可观测性第一反应就是多打印日志。但真正有效的可观测性并不是日志越多越好。如果日志里全是start processing done error retryAgent一样看不懂。真正有价值的是日志之间存在上下文关系。例如一次请求进入Gateway。调用User Service。再调用Order Service。Order Service查询数据库。然后调用Payment。最后返回。如果每一层都有自己的日志但没有统一Trace IDAgent仍然要猜哪些日志属于同一个请求。而如果整个链路都有trace_id xxxxx那Agent可以完整看到一次请求到底经历了什么。所以可观测性的价值不是产生更多文字。而是让系统状态可关联、可定位、可解释。四、Agent真正需要的其实是一条Evidence链比如一个接口变慢。只知道“响应时间超过5秒。”这只是现象。真正完整的证据链可能是接口P95从800ms上涨到5秒↓Tracing显示80%的耗时集中在数据库↓数据库Metrics显示锁等待上升↓日志显示某批处理任务长期占用事务↓问题开始时间与新任务上线时间一致这时候你再让Codex分析结论就不再依赖猜测。它可以得到一个相对完整的因果链。这也是为什么以后Agent排错里真正重要的可能不是模型能不能想到更多可能性。而是系统能不能提供足够好的证据让它排除错误可能性。五、更深一层AI越能自动修复错误证据反而越不能模糊假设未来Agent真的可以做到发现异常。定位问题。修改代码。自动跑测试。部署修复。如果一开始的判断就是错的后面所有自动化都会沿着错误方向继续。比如真实问题是数据库锁。Agent却因为日志不清楚判断成接口代码效率低。于是它重构Service。增加缓存。修改调用逻辑。测试通过。结果真正问题还在。甚至系统变得更复杂。所以Agent自动执行能力越强错误诊断的代价也越高。以前人判断错了可能只是浪费半小时。以后Agent判断错了可能十分钟内已经改了十几个文件。这就是为什么Agent时代Evidence质量会变得越来越重要。六、可观测性正在从“故障之后使用”变成“Agent执行前提”传统监控经常是系统出问题以后才看。但Agent时代可能会变成执行任务之前先读取系统状态。比如准备优化数据库查询。Agent可以先看当前P50。P95。P99。慢查询比例。CPU。IO。连接池。然后再修改。改完以后重新比较指标有没有真正改善。这时候可观测性就不再只是发现问题。还承担验证修改效果。于是整个Agent闭环变成观察→ 判断→ 修改→ 验证→ 再观察如果没有Observability这个闭环中最前面和最后面都会缺失。七、为什么“Tests Passed”还不够因为测试只能告诉你在当前测试条件下行为符合预期。但真实系统还有负载。并发。真实数据。网络延迟。第三方依赖。资源竞争。这些东西很多不会完整出现在测试环境里。比如Agent修复一个性能问题。测试全过。但上线以后P99延迟从2秒变成5秒。如果系统没有指标监控Agent根本不会知道自己虽然“修绿了测试”却把真实性能搞差了。所以真正成熟的AI修复Workflow需要代码Evidence 测试Evidence 运行时Evidence。缺任何一层判断都可能不完整。八、Agent为什么比人更需要结构化日志因为人可以读一句“用户订单创建失败可能是支付超时。”然后结合经验理解。Agent更适合的是eventorder_create_failed order_id123 payment_servicetimeout latency_ms5023 retry_count3 trace_idabc这种结构化信息。因为它可以直接筛选。聚合。关联。比较。所以未来可观测系统很可能会越来越从给人看的日志转向人和Agent都能直接消费的数据。这也是一个很重要的变化。九、真正值得看的不是日志数量而是“关键路径有没有被看见”比如一个关键支付流程有10个阶段。但系统只能看到入口日志。最终报错。中间8个阶段完全黑盒。这时候无论日志总量有多大真正可观测覆盖率都不高。所以这篇我建议只看一个指标Observability Coverage Rate——可观测覆盖率可以简单计算关键业务流程中能够明确看到输入、状态、耗时、错误原因和上下游关系的关键阶段数 ÷ 总关键阶段数。例如一个订单流程有10个关键阶段。其中只有6个阶段能够被清晰追踪。那么可观测覆盖率 60%。这个数字比“我们每天有多少GB日志”有意义得多。十、可观测覆盖率低于40%Agent其实还在大量“猜”如果很多关键流程只能看到开始。结束。失败。中间几乎没有Evidence。那么Agent再强也只能读代码。推测。尝试。再验证。这时候AI看起来很能干。但真正效率并不高。因为它把大量时间花在补系统本应该直接告诉它的信息。十一、40%—70%重点应该补关键黑盒这个阶段通常已经有日志。Metrics。部分Tracing。但某些关键路径仍然看不清。最值得做的不是所有地方都疯狂加日志。而是找出哪些黑盒最经常让人和Agent停下来猜。比如数据库调用。外部API。异步任务。权限链路。队列消费。把这些关键节点补齐投入产出比通常最高。十二、长期超过70%Agent自治能力才真正容易提高如果大部分核心流程都可以看到输入是什么。执行到了哪一步。每一层耗时多少。状态怎么变化。错误在哪里发生。上下游是什么。那么Agent就能真正做到少问人。少猜。更快定位。甚至自动判断改完以后问题有没有改善。这时候“自主修复”才不只是一个概念。十三、怎么提高可观测覆盖率1. 统一Trace ID跨服务、跨队列、跨任务时保持同一条链路可追踪。这是最基础的一步。2. 日志尽量结构化不要只写“处理失败”。而是写清楚什么失败。哪个资源。当前状态。错误类型。耗时。3. Metrics不仅看系统还要看业务除了CPU。内存。磁盘。也应该看订单失败率。任务重试率。接口P95。队列积压。业务异常比例。4. 给Agent保留“修改前后对比”例如优化一个接口修改前P952.8秒。修改后P95900ms。这种证据比一句“性能优化完成”可信太多。十四、为什么Tracing会越来越重要因为Agent处理复杂系统时最大困难之一就是跨服务调用链。一个前端报错真正问题可能在第五个下游服务。没有TracingAgent只能分别查日志。再自己拼时间线。有Tracing整个链路直接展示出来。所以系统越复杂Agent越需要端到端可追踪。十五、还有一个很容易忽略的地方失败路径必须可观察很多系统对正常流程记录很完整。但异常路径反而日志很少。比如成功时记录订单创建成功。支付成功。库存成功。但失败时只有Operation failed。这对Agent非常不友好。因为真正排错时最需要的是错误发生前最后一个正常状态是什么失败以后系统做了什么是否Retry是否Rollback是否产生副作用所以Agent时代最值得增强的往往不是Happy Path。而是Failure Path Observability。十六、可观测性为什么会直接影响人工接管成本昨天仙逆讲过一个问题Agent跑很久以后人重新接管很贵。可观测性其实正好能降低这个成本。如果Agent可以直接告诉人当前Trace。失败节点。已尝试方案。修改前后指标。剩余风险。人就不用重新读几十个文件才知道任务到底发生了什么。所以可观测性不仅是Agent的感知系统。也是人机之间共享状态的接口。十七、Plus和Pro怎么判断如果你的可观测覆盖率还很低很多Agent任务一遇到问题都只能猜。读大量代码。反复试。问人补上下文。那当前真正限制效率的不是AI容量。而是系统本身没有提供足够清晰的Evidence。这种阶段Plus通常已经足够。更值得先完善结构化日志。Tracing。Metrics。请求ID。错误分类。修改前后指标。否则提高更多AI容量以后只是让Agent拥有更多“猜测和试错”的机会。如果你的可观测覆盖率已经很高关键流程基本透明。异常很容易定位。Agent可以自己读取Evidence。修改以后也能自动比较指标。人工介入很少。同时又长期存在大量成熟任务排队。多个Agent持续工作。AI侧容量真正开始限制吞吐。这时候Pro才更容易产生价值。因为增加的AI容量是在一个看得清、能验证的系统里工作。而不是黑盒里盲试。十八、Agent时代真正重要的不只是“会修”而是“知道为什么修”这可能是整个趋势最重要的一层。如果Agent只是看到报错。改代码。测试通过。那它本质上还是高级自动化工具。但如果它能够读取运行状态。找到异常Evidence。建立故障链。修改代码。再用真实运行数据验证结果。它才开始接近真正能够独立处理工程问题的开发Agent。而这一切的前提不是更长Prompt。也不只是更强模型。而是系统有没有把真实世界状态暴露出来。最后ChatGPT、Codex越来越能自己处理真实工程任务以后我们很容易把注意力全部放在模型能力。Agent能力。工具调用。自动修改。但越往后我觉得越会发现Agent真正的上限很大程度上取决于系统到底有多透明。一个看不见内部状态的系统再强的Agent也只能猜。一个Evidence完整的系统即使问题复杂Agent也可以一步步缩小范围。所以未来可观测性可能不只是SRE或者运维团队关心的东西。它会越来越变成AI开发Workflow本身的一部分。因为Agent要真正自己发现问题、修问题、验证结果它首先必须拥有一双能够看见系统的“眼睛”。而日志、Metrics、Tracing和Evidence链就是这双眼睛。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。