Agent 系统的发展可以按一条工程主线来理解：模型接入外部能力、组织推理路径、利用执行反馈、管理长期记忆、沉淀可复用技能，最后进入 Harness 工程。这条主线的核心变化在于，LLM 不再只是一个文本生成组件，而是逐步扩展为任务执行过程中的决策组件——模型判断下一步动作，外部模块提供知识、计算、工具和环境反馈，状态系统负责过程记录，运行时则负责推进整个任务。
本文将梳理十篇代表性论文，它们分别解决这条链路上的不同问题：MRKL 解决能力如何模块化接入；Toolformer 和 ToolLLM 解决工具如何被模型稳定调用；Tree of Thoughts 解决复杂问题下如何搜索和评估中间推理；Reflexion 解决失败经验怎么进入下一轮执行；Generative Agents 解决长期记忆如何支撑行为一致性；Voyager 解决开放环境中技能怎样积累和迁移；Agent Harness Engineering 则把这些机制组合成一个可工程化的生产系统。
1 外部能力接入
MRKL Systems 给出了一个很早但非常关键的判断：LLM 适合做自然语言入口，外部知识源、计算器、数据库和专用推理模块适合承担确定性能力。
这个判断把 Agent 从单模型思路拉到了系统架构思路：模型不承担全部计算和知识职责，而是负责理解输入、判断意图、选择模块，具体能力由外部模块完成。这一步的工程意义在于，Agent 系统需要一个能力路由层，这个路由层决定是调用模型、调用工具、查询数据库还是调用专用模块。后续的工具调用、协议标准、插件系统乃至 MCP 生态，都可以放在这个方向下去理解。
2 工具调用能力
Toolformer 把工具调用推进到了模型能力层。模型通过自监督方式学习插入 API 调用，自主判断什么时候调用工具、调用哪个工具、传入什么参数，并把工具返回结果用于后续生成。它的重点在于“工具调用变成了模型生成过程的一部分”，证明模型可以通过少量示例和自动过滤数据，学会调用计算器、搜索、翻译、日历等工具。
ToolLLM 则进一步放大了工具调用的规模。它面向真实世界 API 构建了 ToolBench，从 RapidAPI 收集大量接口，生成单工具和多工具任务，标注调用路径，再通过 API Retriever 缩小候选工具空间，并借助 ToolEval 评估调用过程。
这一步的工程意义在于，工具调用不再只是“模型会不会调一个函数”，它变成了工具目录、工具检索、参数生成、多步调用、调用路径评估和失败处理的完整系统问题。
3 推理路径组织
Tree of Thoughts 处理的是决策路径问题。在复杂任务中，模型一次生成一个答案很容易受早期选择的影响，而 ToT 把中间推理步骤表示为 Thought，再把多个 Thought 组织成一棵搜索树。
ToT 的价值在于将模型推理过程显式化：系统可以生成多个候选路径，评估每一个中间状态，保留更好的路径，并在路径不合适时回溯。这对 Agent 来说很重要，因为 Agent 的动作通常会连带后果——工具调用、文件修改、代码执行、流程触发都需要更稳的决策过程。树形搜索和状态评估为任务编排提供了基础思路。
4 反馈与记忆
Reflexion 解决的是执行后如何利用经验的问题。模型执行任务后会得到各种反馈——可能是二值结果、评分、测试失败、环境报错，也可能是自然语言评价。Reflexion 将这些反馈转化为反思文本，写入记忆，并在下一轮执行时把这些经验作为上下文。
这个机制的工程价值非常直接：Agent 需要把失败经验转化成可复用的执行约束，比如某个接口参数容易出错、某类代码需要先跑单测、某个环境状态下不能直接执行下一步。
Generative Agents 则处理更长期的记忆问题。它使用 Memory Stream 记录完整经验，再按相关性、近因性和重要性去检索记忆，通过反思形成更高层的结论，通过规划生成后续行为。
这一步把 Agent 的状态管理问题讲得很清楚：长期行为的一致性来源于记忆检索、反思和规划的组合。原始历史记录需要进入记忆流，重要经验需要被提炼，当前行动需要读取相关记忆。
5 技能沉淀
Voyager 把 Agent 放进开放世界环境，它在 Minecraft 中持续探索、自动生成课程、执行代码动作、读取环境反馈、修正程序，再把成功程序写入技能库。
Voyager 的关键点在于：技能是以可执行代码的形式沉淀下来的，技能描述进入向量库，后续任务通过检索找到相似技能，再组合出更复杂的动作。这一步把 Agent 的学习方式从“记住一段经验”推进到了“积累可执行能力”。技能库承担长期能力复用的职责，自动课程承担任务生成职责，自验证承担结果确认职责。
6 Harness 工程
前面这些论文各自解决了 Agent 的某些组件能力，Agent Harness Engineering 则把这些组件纳入一个统一的工程层，称为 Harness。Harness 是包裹在模型外层的执行系统，它管理执行环境、工具接口、上下文、生命周期、可观测性、验证和治理。
这一套结构把前面几篇论文串了起来：
MRKL、Toolformer、ToolLLM 主要落在 Tooling，处理外部能力如何被接入和调用。Tree of Thoughts 主要落在 Lifecycle 和 Verification，处理推理路径生成、状态评估和搜索控制。Reflexion 连接 Lifecycle、Context 和 Verification，把反馈转成经验，再影响下一轮执行。Generative Agents 主要落在 Context 和 Lifecycle，处理长期记忆、反思、规划及多主体行为。Voyager 横跨 Execution、Context、Lifecycle 和 Verification，把代码动作、环境反馈、自验证和技能库置入持续探索过程。
Harness 工程的价值在于，它把这些机制从论文原型推进为工程架构。系统需要执行环境承载动作，需要工具接口连接外部能力，需要上下文管理任务信息，需要生命周期推进过程，需要可观测性记录事实，需要验证机制判断结果，需要治理机制控制边界。
7 一条完整的 Agent 执行链路
综合这些论文，一个生产级 Agent 的执行链路可以这样组织：
任务目标进入系统后，先构建上下文，模型生成计划，搜索机制评估不同路径，工具层选择可用能力，执行环境完成动作，结果观察进入验证模块；失败结果转成反思，成功动作进入技能库，状态更新后继续下一轮执行。这条链路比单次模型调用更接近真实的 Agent 系统——模型调用只负责一次判断，Harness 负责完整任务过程，而任务过程包含状态、工具、反馈、验证、记忆和治理。
8 工程落地的几个判断
Agent 平台建设可以按能力依赖逐步推进。
- 第一阶段：建设工具接口。 系统需要把业务能力封装成清晰、稳定、可校验的工具，工具数量要可控，工具描述要面向模型使用，工具调用要记录参数、结果和状态。
- 第二阶段：建设上下文和状态。 系统需要区分当前上下文、会话状态、长期记忆、执行日志和中间产物。当前上下文服务模型推理，状态系统服务任务恢复和审计。
- 第三阶段：建设任务编排。 系统需要状态机、步骤调度、超时控制、失败重试和人工确认。复杂任务需要显式地表达执行阶段和终止条件。
- 第四阶段：建设反馈和验证。 系统需要判断结果是否满足目标，失败的根源到底来自模型、工具、上下文、环境还是权限，验证结果必须进入回归反馈。
- 第五阶段：建设技能库。 系统需要把成功动作、流程模板、代码片段和业务经验沉淀为可检索、可组合、可复用的能力。
- 第六阶段：建设治理和观测。 系统需要
Trace、成本统计、权限控制、审计日志和高风险动作拦截。
这个顺序符合 Agent 系统的工程依赖：工具提供动作，状态记录过程，编排推进任务，验证提供反馈，技能沉淀经验，治理控制风险。
9 总结
这几篇论文共同指向一个结论：Agent 工程的核心对象就是任务执行链路。
MRKL 给出了模块化能力接入，Toolformer 给出了模型自学习工具调用，ToolLLM 给出了大规模真实工具生态，Tree of Thoughts 给出了推理搜索机制，Reflexion 给出了反馈记忆机制，Generative Agents 给出了长期行为架构，Voyager 给出了开放环境中的技能积累，Agent Harness Engineering 给出了生产工程分层。
把这些工作连接起来之后，Agent 的架构轮廓非常清晰：模型负责判断，工具负责动作，环境承载执行，状态记录过程，记忆保存经验，验证提供反馈，技能库沉淀能力，Harness 负责把这些部分组织成稳定运行的系统。Agent 平台的建设方向也很明确——从模型能力扩展到系统能力，从单次推理扩展到持续执行，从工具调用扩展到工具治理，从上下文拼接扩展到状态管理，从结果输出扩展到验证反馈，从原型演示扩展到可观测、可恢复、可审计的工程体系。
在云栈社区这样的技术论坛里，这类 Agent 工程实践正在被越来越多的开发者关注和讨论，从模型到系统、从原理到落地的探索，仍将继续演进。
10 参考文献
发表于 3 小时前
|
查看: 3|
回复: 0
