Operations

1. 前言 在上一篇文章中，我们深入剖析了 Permission, Approval & Sandbox 的设计——Agent 如何在拥有强大执行能力的同时，通过多层防御体系保证安全可控。如果说 Agent Loop 是 Agent 的"心跳"，Tool System 是"双手"，Context Management 是"记忆系统"，SubAgent System 是"团队协作能力"，Permission & Sandbox 是"免疫系统"，那么 Observability & Operations（可观测性与运维）就是 Agent 的"神经系统"——它决定了 Agent 在生产环境中能否被监控、追踪、调试和治理。 当 Agent 真正部署到生产环境——作为 CLI 工具被数千名开发者日常使用、作为后台服务持续运行数周、作为编码助手修改关键代码——可观测性变成了Agent的基本能力。 可观测性不是简单的打日志，报个监控，而是一组更根本的问题： Agent 的一次运行，事后能不能完整回放和审计？ Agent 正在做什么，当前处于什么状态，有没有卡住？ 子 Agent、后台任务、定时调度——这些异步执行单元能不能被追踪？ 出问题后，第一现场在哪里？如何区分是模型问题、工具问题、上下文问题还是系统问题？ Token 消耗、API 延迟、工具调用耗时——这些成本指标能不能被量化和管理？ 会话能不能被恢复、归档、导出、切换？这些运维动作是不是系统的一等能力？ 本文是 Agent 实现原理系列的第六篇，继续参考 Codex CLI、Claude Code、nanobot、pi 四个主流开源项目的实现，从工程角度总结 Agent 可观测性与运维体系的设计原则和关键权衡。 2. 可观测性是 Agent Runtime 的骨架 2.1 从"打点日志"到"多层信号体系" Agent 的运行过程不是一条直线，而是一棵分叉的树——有主会话、有子 Agent、有后台任务、有定时调度、有工具调用链、有压缩边界、有权限决策点。单靠几条零散的 log，在出问题时根本无法还原"当时到底发生了什么"。 更深一层看，可观测性之于 Agent，就像飞行数据记录仪之于飞机——不是为了日常飞行时盯着看，而是为了两件事： 事后可恢复：会话中断了能继续，系统崩溃了能重建状态 事中可诊断：运行时能判断 Agent 是正常推理、卡在工具执行、还是在等待用户审批 因此，一个 production-grade Agent Runtime 的可观测性，不是"有空再补点日志"，而是和主执行链同等级的基础设施。它至少需要覆盖五种不同粒度：会话级（transcript、session metadata）、任务级（background task status、task output）、工具级（tool call 轨迹、shell output、permission 事件）、平台级（analytics、tracing、metrics）、运维级（状态快照、健康检查、成本追踪）。 ...