写代码的人可能没想到，有一天修bug的活会被四个AI代理包圆了。而且它们不光干活，还懂得全程“自我观察”——每一段思考、每一次工具调用都变成一条可追溯的轨迹。这就是我在SigNoz黑客松上捣鼓出来的东西：AgentOps。
整个流程拆开看，像一条流水线：Monitor盯着日志，Diagnosis分析痕迹，Fix动手改代码，最后Verify验货。没有人在中间喊“停一下，我看看”，从发现异常到服务恢复正常，时间压在30到60秒。
先看Monitor。它每隔四秒查一次SigNoz，只问一个问题：“从上一次检查到现在，demo-api有没有新的错误span？”它不靠什么神奇后门，获取信息的方式跟值班工程师打开可观测后台一模一样。而且它一次LLM都不调，阈值是纯确定性的。这个代理的“智能”不在推理，而在把检测变成持续的自动循环。
等到Monitor抓住异常，Diagnosis上场。它会从SigNoz拉出ERROR日志和整条调用链，把这些原始证据喂给语言模型，然后强硬要求只返回JSON：文件、行号、根因。结果就是src/index.ts:87。到这一步，Diagnosis根本没看过源代码，更没偷瞄过任何答案提示。它面对的只有痕迹数据，却精准锁定了问题点。
Fix拿到文件名和行号后，通过一个沙盒化的文件系统MCP服务器读取嫌疑文件，再让LLM给出一份最小的补丁。改完先在本地验一验，通过就写入，接着重启服务。万一补丁把服务搞崩了，立即回滚到原始字节，毫不恋战。
Verify做的事情直接得像个验收员：重放刚才导致500的那条请求，死等一个404。收到正确的状态码还不算完，再跑去SigNoz查一遍，确认没有新的错误冒出来，才算盖章通过。
为了让整个演示更硬核，我没自己写一个“故意埋一个bug，然后修好给你看”的示例程序。那种自己挖坑自己填的把戏没意思。我直接把Andrew Knight用MIT协议开源的BuggyBoard搬了过来——一套Express+TypeScript+SQLite的bug跟踪器。我在它的not-found guard里塞了一个缺陷：把 if (!bug) 改成了 if (!bug.id)，导致对不存在的id做null解引用，Express直接甩出500而不是404。一个枯燥、真实到让人翻白眼的bug。
更有趣的是，这四个代理并不是把SigNoz当成一个事后汇报的工具。通过SigNoz MCP服务器，它们直接把SigNoz变成了自己的“感知皮层”——每调动一次工具、每做一回决策，都在那上面留下span。也就是说，你盯着SigNoz的界面，看到的不再是冷冰冰的告警，而是四个代理在想什么、在干什么、哪个环节卡了壳。
所以AgentOps的演示虽然落脚在自愈，但它真正想表达的东西是：当我们越来越多的软件行为由AI代理驱动，可观测的对象必须从静态的服务，延伸到这些代理的思考流和工具链。这一次，它们修好了一个bug，顺便也让我们看清了它们自己的工作方式。
热门跟贴