1. 从执行记录切入Coding Agent 到底在做什么Coding Agent 这个词最近半年被聊得很多但大部分讨论都停留在“它能帮我写代码”这个层面。我一开始也是这么理解的直到有一次排查一个线上问题翻看 Agent 的执行记录时才发现它做的事情远比“写代码”复杂得多。它实际上是在一个循环里不断地观察环境、做决策、执行动作、再观察结果这个循环就是大家常说的 AgentLoop。我接触过的 Coding Agent 大致分两类。一类是嵌在编辑器里的比如各种 IDE 插件形态的助手它们的特点是上下文感知强能直接读取当前文件、光标位置、打开的项目结构。另一类是命令行形态的比如最近讨论度很高的 codex 这类工具通过命令行交互能执行 shell 命令、读写文件、跑测试。两类工具的核心机制其实是一样的都是“感知-决策-执行”的循环区别只在于感知的输入源和执行的动作空间不同。为什么这个循环值得单独拿出来讲因为一旦你理解了 AgentLoop 的结构很多看似神秘的行为就变得可解释了。比如为什么它有时候会反复执行同一个命令为什么它会突然去读一个看起来不相关的文件为什么它会在某个步骤卡住不动。这些现象背后都是循环里的某个环节出了问题而不是“模型变笨了”。从执行记录的角度看一个完整的 AgentLoop 通常包含这几个阶段接收任务描述、规划下一步动作、调用工具执行、解析执行结果、判断是否继续循环。每个阶段都会产生记录这些记录就是后面做审计和风险调查的基础素材。我见过不少人只关注最终输出忽略了中间过程结果出了问题完全不知道从哪查起。提示如果你正在用任何 Coding Agent第一件事应该是找到它的执行记录在哪里。大部分工具会把它存在本地某个目录下格式可能是 JSONL 或者纯文本日志。找到它你就有了排查问题的第一手材料。2. 执行记录里藏着什么结构拆解与关键字段2.1 一条典型执行记录的组成我拿一个实际项目里的记录来拆。当时让 Agent 帮忙修复一个单元测试失败的问题它产生的记录大致是这样的结构时间戳、会话 ID、步骤序号、动作类型、动作参数、执行结果、耗时。这几个字段看起来简单但每一个都有讲究。时间戳和步骤序号用来还原执行顺序这个在排查“为什么它先做了 A 再做 B”这类问题时特别有用。动作类型标识了这一步是读文件、写文件、执行命令还是调用某个特定工具。动作参数记录了具体的文件路径、命令内容或者搜索关键词。执行结果则是工具返回的原始输出可能是文件内容、命令的 stdout/stderr也可能是错误信息。我特别想强调的是执行结果这个字段。很多人看记录只看动作类型和参数觉得知道它做了什么就够了。但实际上Agent 下一步的决策完全依赖于上一步的执行结果。如果结果被截断了、被错误解析了Agent 就会基于错误的信息做决策然后一路错下去。我遇到过好几次 Agent 反复修改同一个文件的情况最后查记录发现是它读取文件内容时被截断了只看到了前半部分以为后面的代码不存在。2.2 动作类型的分类与含义把动作类型分个类对理解 Agent 行为很有帮助。我一般分成四类读取类、写入类、执行类、通信类。读取类包括读文件、搜索代码、查看目录结构。这类动作是 Agent 获取信息的手段风险相对低但量大。写入类包括创建文件、修改文件、删除文件。这类动作直接改变项目状态是审计的重点。执行类包括跑命令、跑测试、跑构建。这类动作可能产生副作用比如修改了数据库、发了网络请求。通信类包括向用户提问、请求确认、输出中间结果。为什么要这么分因为不同类别的动作风险等级和审计策略完全不同。读取类动作出问题通常是信息不完整导致决策偏差写入类动作出问题可能直接破坏代码执行类动作出问题可能影响外部系统。我在做风险调查时会优先看写入类和执行类的记录读取类只在需要还原决策链路时才细看。2.3 记录中的隐藏信息除了显式字段执行记录里还有一些隐藏信息值得挖掘。比如动作之间的时间间隔。如果两个步骤之间隔了很久可能是 Agent 在等待某个操作完成也可能是它在做很长的推理。再比如同一个动作被重复执行的次数。如果某个读文件动作连续出现了五次说明 Agent 可能陷入了某种循环或者它在反复确认同一个信息。还有一个容易被忽略的点是记录里的错误信息。很多工具会把工具调用的失败信息也记进去比如文件不存在、命令返回非零退出码、权限不足。这些错误信息是判断 Agent 是否“迷路”的重要线索。我一般会先扫一遍记录里的错误看看有没有反复出现的失败模式这往往能快速定位问题所在。3. AgentLoop 的运作机制为什么它会这样决策3.1 循环的驱动力来自哪里AgentLoop 的驱动力来自任务描述和当前状态的差距。Agent 每执行一步都会重新评估“任务完成了吗”如果没有完成就继续规划下一步。这个评估过程依赖于模型对任务的理解和对当前状态的感知。这里有个关键点Agent 对“任务完成”的判断标准往往和人类不一致。比如你让它“修复这个 bug”它可能认为只要测试通过了就算完成但实际上测试通过不代表 bug 真的修好了可能只是测试用例没覆盖到。这种判断标准的差异是很多“Agent 说完成了但实际没完成”问题的根源。我在实际使用中总结出一个经验给 Agent 的任务描述要尽量具体最好包含明确的完成标准。比如不要说“优化这段代码”而要说“把这段代码的时间复杂度从 O(n²) 降到 O(n log n)并保证现有测试全部通过”。完成标准越明确Agent 的循环终止条件就越清晰跑偏的概率就越低。3.2 工具调用背后的决策逻辑Agent 选择调用哪个工具、传什么参数这个过程是模型推理的结果。但模型推理不是凭空发生的它依赖于几个输入系统提示词、任务描述、历史执行记录、当前环境状态。系统提示词决定了 Agent 的行为边界和工具使用偏好。不同的 Coding Agent 产品系统提示词的设计差异很大。有的会明确告诉 Agent“优先读文件再改文件”有的会强调“每次修改后必须跑测试”。这些提示词里的规则会直接影响 AgentLoop 的走向。历史执行记录是 Agent 的“记忆”。它会把之前的动作和结果作为上下文来决定下一步做什么。这就解释了为什么 Agent 有时候会“记住”之前读过的文件内容即使当前步骤没有重新读取。但记忆是有限的上下文窗口满了之后早期的记录会被丢弃Agent 就可能“忘记”之前做过什么导致重复劳动或者前后矛盾。3.3 循环失控的几种典型模式我见过几种典型的循环失控模式每一种都能在执行记录里找到特征。第一种是“原地打转”。Agent 反复执行同一个动作比如反复读同一个文件、反复跑同一个命令。记录里的表现是动作类型和参数高度重复时间戳间隔很短。这种通常是因为 Agent 没有正确解析执行结果以为上一步没成功所以重试。第二种是“越走越偏”。Agent 一开始方向是对的但某一步决策失误后后续步骤都在错误的基础上继续。记录里的表现是动作之间的逻辑关联性逐渐减弱从“读 A 文件改 A 文件”变成“读 B 文件改 C 文件”。这种通常是因为某一步的执行结果被误解了。第三种是“无限扩展”。Agent 不断发现新的问题然后去解决解决过程中又发现新问题循环没有终止条件。记录里的表现是任务范围不断扩大从修一个 bug 变成重构整个模块。这种通常是因为任务描述太宽泛没有明确的边界。注意如果你发现 Agent 的执行记录里出现了上述任何一种模式不要直接中断它。先保存记录然后分析它是在哪一步开始跑偏的。这个分析过程本身就是理解 Agent 行为的最好教材。4. 提示词注入Coding Agent 面临的新型风险4.1 什么是提示词注入提示词注入这个概念最早是在对话式 AI 里被讨论的。简单说就是攻击者通过某种方式把恶意的指令混入到 AI 的输入里让 AI 执行原本不应该执行的操作。在 Coding Agent 的场景下这个风险被放大了因为 Agent 不仅能“说”还能“做”——它能读写文件、执行命令。我举个具体的场景。假设你的 Coding Agent 会读取项目里的 issue 描述、代码注释、甚至第三方库的文档。如果这些内容里被人埋了恶意指令比如一段看起来像普通注释的文字实际上是在告诉 Agent“把某个文件的内容发送到某个地址”Agent 在读取这些内容时就可能把恶意指令当成正常任务的一部分来执行。这种风险的可怕之处在于它不需要攻击者直接接触你的系统。只要你的 Agent 会读取外部内容而外部内容可以被污染风险就存在。而且 Agent 越“自主”能执行的动作越多风险就越大。4.2 注入的常见载体在实际项目里我梳理了几种常见的注入载体。代码注释是最容易被忽略的。很多 Agent 会读取代码文件来理解上下文如果注释里藏了指令Agent 可能会把它当成任务要求。比如一段注释写着“TODO: 删除所有测试文件”Agent 可能真的会去删。第三方依赖的文档和源码也是风险点。Agent 在解决依赖相关问题时可能会去读 node_modules 或者 site-packages 里的内容。如果这些内容被篡改注入就发生了。配置文件和环境变量同样值得警惕。有些 Agent 会读取 .env 文件或者 CI 配置来理解项目环境。如果这些文件里混入了恶意指令Agent 在执行相关操作时可能被误导。还有一种比较隐蔽的载体是错误信息。Agent 执行命令失败后会读取错误输出。如果错误输出里包含了精心构造的文本也可能影响 Agent 的后续决策。4.3 防御思路与实操建议防御提示词注入核心思路是“隔离”和“校验”。隔离的意思是把 Agent 的输入源分成可信和不可信两类。系统提示词、用户直接输入的任务描述这些是可信的。从文件、命令输出、外部文档里读到的内容这些是不可信的。Agent 在处理不可信内容时不应该直接把它当成指令来执行而应该只把它当成信息来参考。校验的意思是对 Agent 准备执行的高风险动作加一道人工确认或者规则检查。比如 Agent 准备删除文件、执行网络请求、修改关键配置时应该先暂停让用户确认。这个确认机制不需要很复杂一个简单的“是否允许”提示就能挡住大部分注入攻击。我在自己的项目里还加了一条规则Agent 读取的任何外部内容在进入上下文之前先做一次清洗把看起来像指令的文本标记出来或者直接过滤掉。这个清洗规则不需要很完美只要能挡住常见的注入模式就行。提示不要指望模型自己能识别出注入。模型的设计目标是“有用”不是“安全”。安全边界应该由工具层和流程层来保证而不是寄希望于模型的判断力。5. 审计视角如何调查一次 Agent 行为5.1 审计的目标与范围对 Coding Agent 做审计目标通常有三个还原发生了什么、判断是否合规、找出改进点。还原是基础合规是要求改进是目的。审计的范围取决于你的关注点。如果只是排查一个具体问题范围可以限定在相关会话的执行记录。如果是要评估 Agent 的整体行为模式范围就要扩大到一段时间内的所有会话。如果是应对合规要求范围可能还要包括 Agent 的配置、权限设置、工具清单。我一般会先明确审计的触发条件。是出了问题要查原因还是定期做健康检查还是为了满足某个合规要求。不同的触发条件审计的深度和广度不一样。出问题时的审计要快、要准定期检查可以慢、可以全合规审计则要严格按清单来。5.2 审计的执行记录分析方法分析执行记录我习惯分三步走先看全局再看异常最后看细节。看全局是快速扫一遍记录了解这次会话大概做了什么。我会看会话的总步骤数、动作类型的分布、有没有明显的错误。这一步不需要细看每个动作主要是建立整体印象。看异常是找出记录里“不对劲”的地方。异常包括反复出现的动作、长时间没有进展的步骤、错误信息集中的区域、动作类型突然变化的地方。这些异常点往往是问题的所在。看细节是围绕异常点把前后的记录串起来看。比如发现某个步骤反复执行了五次我会看这五次之间有没有差异每次的执行结果是什么Agent 在第五次之后做了什么。通过这个细节分析通常能还原出 Agent 当时的“想法”。5.3 审计中的常见发现我做过几次 Agent 行为审计总结出几个高频发现。第一个是权限过大。很多 Agent 默认拥有读写整个项目目录的权限甚至能执行任意命令。这在方便的同时也意味着一旦 Agent 决策失误或者被注入影响范围会很大。审计时我会检查 Agent 的实际权限看看有没有可以收窄的空间。第二个是记录不完整。有些工具默认不记录完整的执行结果只记录动作类型和参数。这给审计带来很大困难因为你不知道 Agent 当时看到了什么。如果工具支持配置记录级别建议至少把执行结果也记下来。第三个是缺少人工确认环节。很多高风险动作比如删除文件、执行部署命令Agent 直接就做了没有给用户确认的机会。审计时我会标记出这些动作建议在流程里加上确认步骤。第四个是上下文管理问题。Agent 的上下文窗口有限长会话里早期信息会被丢弃。审计时我会关注会话长度看看有没有因为上下文丢失导致的重复劳动或者前后矛盾。6. 工具选型LoongSuite-Pilot 与同类方案的对比6.1 LoongSuite-Pilot 的定位LoongSuite-Pilot 是我最近在关注的一个 Coding Agent 工具。它的定位偏向“可审计、可控制”在执行记录的完整性和权限管理上做得比较细。和那些追求“全自动”的工具不同它更强调人在回路里的作用高风险动作会主动请求确认。这个定位适合什么场景我觉得适合对安全性和可追溯性有要求的团队。比如金融、医疗这类受监管行业或者任何需要事后审计的开发流程。如果你只是个人项目随便用用可能觉得它有点“啰嗦”但如果你需要向别人解释“Agent 到底做了什么”它的记录能力就很有价值。6.2 同类方案的对比维度选 Coding Agent 工具我一般看这几个维度执行记录的详细程度、权限控制粒度、工具调用的可扩展性、上下文管理策略、以及是否支持人工确认。执行记录详细程度决定了你事后能查到什么。有的工具只记动作有的记动作加结果有的连模型的推理过程都记。记录越详细审计越容易但存储和隐私成本也越高。权限控制粒度决定了 Agent 能做什么。粗粒度的控制是“能不能读写文件”细粒度的控制是“能读写哪些目录、哪些文件类型、哪些操作需要确认”。粒度越细安全性越高但配置也越复杂。工具调用可扩展性决定了你能不能给 Agent 加自定义能力。有的工具只支持内置的几种动作有的允许你注册自己的工具函数。可扩展性强的工具能适配更多场景但也意味着更大的攻击面。上下文管理策略决定了长会话的表现。有的工具用滑动窗口有的用摘要压缩有的用向量检索。不同策略在信息保留和性能开销上各有取舍。人工确认机制决定了风险动作的可控性。有的工具默认全自动有的默认每步确认有的支持按规则配置。这个没有绝对好坏取决于你的使用场景和风险偏好。6.3 选型建议我的建议是先明确你的核心需求。如果你最关心的是“出了事能查清楚”那就优先选记录详细的。如果你最关心的是“别让它乱来”那就优先选权限控制细的。如果你最关心的是“能适配我的特殊流程”那就优先选可扩展性强的。不要追求“全能工具”因为全能往往意味着每个维度都只是及格。选一个在你最关心的维度上做到优秀的工具其他维度够用就行。工具是可以组合的比如用 A 工具做日常开发用 B 工具做敏感操作没必要一个工具解决所有问题。注意无论选哪个工具都要先在小范围、低风险的项目里试一段时间。观察它的执行记录看看它的行为模式是否符合你的预期。不要一上来就在核心项目里用出了问题代价太大。7. 实操搭建一套 Agent 行为监控流程7.1 记录采集与存储第一步是确保执行记录被完整采集。大部分工具会把记录存在本地你需要做的是找到它、确认格式、然后决定怎么存储。如果工具支持配置记录级别把它调到最详细。存储位置建议统一到一个固定目录方便后续处理。格式方面JSONL 是比较友好的选择每行一条记录便于解析和检索。存储策略上我建议至少保留最近一个月的记录。如果存储空间紧张可以对旧记录做压缩归档。但不要轻易删除因为很多问题的排查需要回溯到很久之前。7.2 关键指标的提取有了记录之后下一步是提取关键指标。我一般会关注这几个每次会话的总步骤数、动作类型的分布、错误率、高风险动作的次数、人工确认的触发次数。这些指标可以帮你快速了解 Agent 的行为模式。比如错误率突然升高可能是环境变了或者任务变难了。高风险动作次数异常增多可能是任务描述有问题或者 Agent 跑偏了。人工确认触发次数太少可能是权限配置太宽松。提取指标不需要很复杂的工具一个简单的脚本就能搞定。关键是坚持做形成时间序列这样才能看出趋势和异常。7.3 告警与人工介入指标提取之后可以设置一些简单的告警规则。比如单次会话步骤数超过阈值、错误率超过阈值、高风险动作未经确认就执行这些都可以触发告警。告警的目的不是自动阻断而是提醒人去查看。Agent 的行为很多时候需要结合上下文才能判断是否合理自动阻断可能误伤正常操作。人工介入的价值在于人能理解“为什么”而规则只能判断“是什么”。我自己的做法是告警触发后先看执行记录判断是正常波动还是真有问题。如果是正常波动调整阈值。如果是真问题分析原因然后决定是改配置、改流程还是改任务描述。7.4 定期复盘与流程优化最后一步是定期复盘。我一般每两周花半小时把这段时间的告警记录和执行记录翻一遍看看有没有反复出现的问题有没有可以优化的流程。复盘的重点不是“抓错”而是“改进”。比如发现某类任务总是需要人工确认那可能是任务描述不够清晰可以优化描述模板。发现某类错误反复出现那可能是环境配置有问题可以提前修复。发现某个工具调用总是失败那可能是工具本身有 bug可以反馈或者换方案。这个复盘习惯坚持下来你会发现 Agent 的使用效率明显提升因为很多问题在变成大问题之前就被解决了。8. 常见问题与排查技巧实录8.1 Agent 反复执行同一个动作怎么办这是最常见的问题。排查思路是先看这个动作的执行结果是什么再看 Agent 在结果之后做了什么。如果执行结果里包含错误信息Agent 可能是在重试。这时候要看错误是什么是环境问题还是参数问题。环境问题需要修环境参数问题需要看 Agent 为什么传错参数。如果执行结果正常但 Agent 还是重复执行那可能是上下文管理出了问题。Agent 可能“忘记”了上一步已经执行过或者它认为上一步的结果不满足某个条件。这时候可以检查会话长度看看是不是上下文被截断了。8.2 Agent 修改了不该修改的文件这种情况通常和权限配置有关。先检查 Agent 的权限范围看看它是否有权访问那个文件。如果有那说明权限太宽需要收窄。如果没有那可能是工具的实现有 bug需要反馈。另一个可能的原因是任务描述有歧义。Agent 可能把“修改配置文件”理解成了“修改所有配置文件”然后动了一个你不希望它动的。这时候需要优化任务描述明确指定文件路径或者排除某些文件。8.3 执行记录不完整或缺失如果发现记录缺失先检查工具的记录配置。有些工具默认只记录部分信息需要手动开启详细记录。如果配置没问题那可能是存储空间满了或者写入权限有问题。还有一种可能是记录被轮转或清理了。检查一下有没有日志轮转策略保留时间是不是太短。如果是调整策略延长保留时间。8.4 如何判断 Agent 是否被注入判断注入比较难因为注入的指令往往伪装成正常内容。我的经验是关注 Agent 的行为是否“偏离任务”。如果 Agent 突然去做一些和任务无关的事情比如访问不相关的文件、执行不相关的命令那就要警惕。另一个信号是动作的“风格”变化。如果 Agent 之前的动作都很规范突然出现一些奇怪的参数或者命令那可能是被注入了。这时候要回溯它最近读取了哪些外部内容看看有没有可疑的。8.5 常见问题速查表问题现象可能原因排查方向解决建议反复执行同一动作结果解析错误、上下文丢失看执行结果、看会话长度修解析逻辑、优化上下文管理修改不该改的文件权限过宽、任务描述歧义查权限配置、查任务描述收窄权限、明确任务边界记录缺失配置问题、存储问题查记录配置、查存储空间开启详细记录、清理存储行为偏离任务提示词注入、任务理解偏差查外部输入、查任务描述隔离不可信输入、优化描述循环无法终止完成标准不明确查任务描述、查终止条件明确完成标准、加步数上限9. 我个人的一些经验体会用 Coding Agent 这段时间最大的体会是它的价值不在于“全自动”而在于“可观察、可干预”。一个完全黑盒的 Agent即使效率再高我也不敢在关键项目里用。因为出了问题我查不了、说不清、改不动。执行记录是我和 Agent 之间最重要的接口。通过它我能理解 Agent 的决策逻辑能发现它的行为模式能在它跑偏之前介入。没有执行记录Agent 对我来说就是个不可信的黑盒。审计也不是为了“抓错”而是为了“建立信任”。当你能够清楚地解释 Agent 做了什么、为什么这么做、结果是什么你才敢把更重要的任务交给它。这个信任是逐步建立的而执行记录和审计流程就是建立信任的基础设施。最后分享一个小技巧我会定期把执行记录里的“典型会话”保存下来作为案例库。新同事上手时先看这些案例比看文档快得多。案例里既有成功的模式也有失败的教训都是真实发生过的比抽象的原则更有说服力。