14. 代码 Agent 的设计模式：前 13 篇的横向梳理

这个系列覆盖了什么

前 13 篇按时间顺序介绍了代码 Agent 领域的主要工作：

篇	论文 / 系统	核心贡献
01	PoT / CoC	用代码外包推理计算
02	CodeSteer	动态选择代码或文本推理模式
03	CodeRL	执行反馈作为 RL 奖励信号
04	Voyager	代码作为技能载体，终身学习
05	CodeAct	代码执行作为通用动作空间
06	Self-Debugging	读错误信息自我修正
07	SWE-agent	ACI 设计，真实 bug 修复
08	Reflexion	语言反思替代梯度更新
09	LATS	树搜索 + 反思
10	AlphaCodium	测试驱动的迭代流程
11	AgentCoder	角色分离，代码生成和测试独立
12	MapCoder	检索类比辅助生成
13	InterCode	标准化的交互式编程 RL 环境

这些工作看起来各自独立，但实际上在反复回答几个相同的核心问题。

维度一：动作空间

问题：Agent 的动作是什么？

不同论文对这个问题的回答有明显分歧：

自然语言 + 工具调用（ReAct 等早期方法）：Agent 输出文字推理步骤，遇到需要计算或查找的地方调用预定义工具。动作空间固定，清晰，但表达能力有限。

代码作为动作（PoT、CodeAct、Voyager）：Agent 直接输出可执行代码。动作空间更大，可以表达任意逻辑，自带验证机制。代价是需要执行环境，有安全风险。

结构化流程动作（SWE-agent 的 ACI）：介于两者之间，定义了一套语义清晰、信息量适中的工具接口，不是完整的编程语言，也不是自然语言工具调用。适合特定场景（软件工程），在该场景下比完整 bash 效果更好。

从这些工作的结果来看，代码作为动作空间的优势是逐渐被确认的趋势，但不是所有场景都需要完整的代码执行能力。

维度二：反馈机制

问题：Agent 从哪里获取改进信号？

反馈来源	代表方法	优势	局限
执行结果（测试通过/失败）	CodeRL、AlphaCodium	精确，无需人工标注	需要测试用例
错误信息（traceback）	Self-Debugging	直接，位置精确	只能处理有明确错误的情况
语言反思	Reflexion	不依赖执行环境	反思质量依赖模型能力
环境奖励	InterCode、CodeRL	标准化，可训练	奖励函数设计困难
参考解法	MapCoder	可复用已有知识	依赖检索库质量

多数成功的方法都使用了多种反馈来源的组合。纯粹依赖某一种反馈的方法，在该反馈缺失时表现会明显下降。

维度三：记忆结构

问题：Agent 怎样把过去的信息带入后续决策？

无显式记忆：Self-Debugging 的基本版本，每次修正只看当前错误信息，不保留历史。适合短任务，开销小。

上下文内记忆（in-context memory）：Reflexion 把反思文本追加进 prompt，LATS 把路径历史带入节点评估。依赖上下文窗口，超出后就会丢失。

外部持久记忆：Voyager 的技能库，用向量数据库存储已学会的代码技能，跨任务持久。存储成本高，检索质量影响效果。

参数记忆（parameter memory）：CodeRL 通过训练把知识编码进模型参数。持久，不占上下文，但需要更新模型，成本高。

实际系统中，这几种记忆结构往往组合使用：上下文内放近期反思，外部数据库放长期技能，模型参数承载基础知识。

维度四：搜索策略

问题：面对不确定性，Agent 如何探索可能的解法？

贪心（Greedy）：每次取最可能的动作，不回溯。Self-Debugging、Reflexion 都是这种结构，快，但容易陷在局部。

采样多路径（Sampling）：生成多个候选（AlphaCodium 的多初始方案、AgentCoder 的多次生成），并行评估，取最好的。成本线性增加，效果有保证。

树搜索（Tree Search）：LATS 的方式，有结构地探索，维护分支、支持回溯。最灵活，但开销最大。

迭代精化（Iterative Refinement）：AlphaCodium、AgentCoder 的主要策略，沿一条路反复改，每次用执行结果驱动修正。适合有明确测试标准的任务。

几个反复出现的权衡

读完这些论文，有几个权衡在不同方法里反复出现：

效果 vs 成本：LATS 和 MapCoder 在 benchmark 上数字好看，但 LLM 调用次数多，延迟高，实际部署中很难用在需要快速响应的场景。Self-Debugging 更简单，效果没那么好，但实用得多。

通用性 vs 专用性：CodeAct 追求通用动作空间，SWE-agent 的 ACI 是针对软件工程场景专门设计的。专用接口在目标场景效果更好，但迁移到其他场景需要重新设计。

端到端 vs 模块化：AgentCoder 和 MapCoder 把任务拆成几个 Agent，每个专注一件事，但引入了模块间的协调开销，也依赖每个模块都足够好。端到端方法（直接生成 + 调试）结构简单，但单个模型需要承担更多。

有执行环境 vs 无执行环境：所有用执行反馈的方法都依赖一个可靠的代码执行环境。这在受控实验里不是问题，在真实部署里需要考虑沙箱安全、依赖安装、执行超时等工程问题。

实际选型的参考

如果要在实际项目里选择 Code Agent 的策略，这几个问题可以帮助缩小范围：

有没有可靠的测试用例？

有 → 测试驱动的迭代方法（AlphaCodium、AgentCoder）效果较好

没有 → Reflexion 或 Self-Debugging，靠模型自身的判断

任务复杂度如何？

简单任务（一两步可以完成）→ 直接生成 + Self-Debugging

复杂任务（需要多步规划）→ 考虑 ReAct 或 LATS

是否有相似问题的历史？

有 → MapCoder 的检索类比策略有参考价值

没有 → 不需要检索

对响应时间有要求吗？

要求快 → 直接生成 + 一两轮 Self-Debugging

不要求快 → LATS 或 AlphaCodium 多轮迭代

这个系列后续

前 14 篇覆盖了基础方法和主要论文。后续计划还有：

代码 Agent 的安全边界（沙箱设计、权限控制）
真实软件工程任务中的上下文管理
代码 Agent 的评测方法设计（超出现有 benchmark 的思考）
多模态代码 Agent（视觉输入 + 代码生成）

（采用 CC BY-NC-SA 4.0 许可协议进行授权）

本文标题:14. 代码 Agent 的设计模式：前 13 篇的横向梳理

本文链接:https://www.sshipanoo.com/blog/ai/code-agent-harness/14-代码Agent设计模式总结/

本文最后一次更新为天前，文章中的某些内容可能已过时！