Coding Agent 执行记录与 AgentLoop 审计：提示词注入风险与监控实践

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 做了什么、为什么这么做、结果是什么，你才敢把更重要的任务交给它。这个信任是逐步建立的，而执行记录和审计流程就是建立信任的基础设施。

最后分享一个小技巧：我会定期把执行记录里的“典型会话”保存下来，作为案例库。新同事上手时，先看这些案例，比看文档快得多。案例里既有成功的模式，也有失败的教训，都是真实发生过的，比抽象的原则更有说服力。