工作流可观测

解决的实际问题

当 Codex 或 CodeBuddy 等编码代理在你的终端里执行多步任务时，很容易发生这些事情：无法回答“刚才那轮改动到底触发了哪些工具调用”、多个 hook 因改动后失效却无人发现的安全问题，以及远程追踪导出静默丢数据却无迹可寻的情况。这些问题会让代理工具里只有功能，谈不上操作上的可信度。在交付一个可被依赖的智能体之前，你要先解决一处最基础也是最容易忽略的地方：如何安全地让运行态可见。

技能如何工作

这个技能让你完成一处闭环可观测部署：登录到目标项目中的接收点，而非单独去调查代码方案。

• 首先定位运行态插件目录：优先识别包含 package.json、src/index.ts 和 hooks/ 的现有目录。如果目标是空白仓库，则从本 skill 附带的 assets/plugin-runtime/ 搭建运行态文件：包括入口处 hook 配置、Codex 入口文件代码，以及要运行的示例 config.env。
• 接着选择目标 Agent。如果当前环境无法明确是 Codex、CodeBuddy 还是两者并存，让你自己只根据现有信息快速判断即可，而不是再问一个可以晚点解决的问题。
• 然后安装好依赖、确认配置参数和密钥均已就位，再将正确的 hook 接入流程分别推入：如 Codex 更新 .codex-plugin/plugin.json 与 hooks/codex-hooks.json；CodeBuddy 则写入 hooks/codebuddy-hooks.json 到项目配置。这之后还要加上一条保护：确认 Codex 自身已启用 hook 支持，features.hooks 为 true，并在 /hooks 或 hooks/list 中看到所有 AOBS hook 已标记为 trusted——注意 hook 更新一次后，以前那个哈希值就不用了，这会让 hook 重新变成未信任。
• 最后执行验证：跑一段 smoke test、触发一次对话后观察 .aobs/exports 目录下是否有生成文件，以及执行是否成功。整个过程遵循 fail-open 原则：即使采集失败也不阻断正常的 Agent 对话。

适用边界与注意点

先把便宜、必需的主链跑通——安装、接上、验证——再考虑是否要对接 Langfuse、CLS 或 OTLP 远程导出。不要一开始就搭建一堆远程服务；先让一次对话产生可被检查的观测结果。它在不改变你工作流逻辑的前提下，从目标仓库的插件目录开始工作，用 src/ 与 hooks/ 共存的标准约定落地，而不是包装你原来的用法。

同时，请闭上眼睛也能记得这几条：

• 不要把 token、密钥或 DSN 明文写进代码或解释性回复里，用 config.env 管理配置；
• 不要用 SKILL.md 里的段落当作运行时代码；
• .aobs 下的事实输出是只读的，值只用于验证和诊断，不要手工修改；