过去一年我断断续续看过几十个Agent项目的代码最让我印象深刻的不是哪个项目用了多强的模型而是大量项目里Agent都是“装饰品”。代码结构基本一个模板一个大System Prompt接上LLM API循环外面包一层工具调用就宣称是Agent了。Demo阶段一切美好等到真实用户进来任务稍长就断工具参数填错不重试用户中途改一句需求直接崩。团队第一反应是“换更强的模型”但换完发现治标不治本。问题出在哪出在架构层还在用“工具”的思路做“伙伴”的事情。“从工具到伙伴的范式跃迁”这句话外面听得很多真正落到工程上其实是一整套可度量的变化行为模型从“指令-执行-返回”变成“目标-感知-决策-行动-记忆-反省”的闭环评价标准从“单次调用有没有答对”变成“长任务能不能兜底完成”。这篇文章是“Agent论文和工业界实战总结”系列的第一篇我会把范式跃迁的几个核心坐标——架构闭环、多Agent协作、沙盒与并发、评测回归、记忆分层——结合论文演进和工业落地经验一次梳理清楚。适合正在做Agent应用开发、准备做Agent架构选型、或者想判断一个Agent系统是否靠谱的读者。1. 范式跃迁的本质工具以“执行”为终点伙伴以“目标”为终点关于Agent的讨论我建议先回到一个朴素的问题我们到底在做一个什么系统这个问题不搞清楚后面所有技术选型都是空中楼阁。传统的工具型系统本质是四个特征锁定输入输出可枚举、行为确定、无内部状态、失败可离线排查。你可以把它想象成一把螺丝刀——你拿它拧螺丝它不会主动告诉你“这个螺丝位置不太对要不要先换个方向”。螺丝刀自己不需要目标它的全部意义在于被使用的方式。而Agent要承担的是“伙伴”才有的责任。伙伴不是机械执行指令的机器它在长期协作中需要具备三种能力第一记住目标本身而不是只记住最近一条指令第二在中间步骤出错时能主动调整路径而不是把错误结果原样返回第三遇到不确定性时知道何时该停下询问人类。这三种能力落到评估体系里就是另一套完全不同的KPI。工具系统的成功标准是“指令执行正确率”比如你调一个API它返回了符合schema的结果这事就成了。Agent系统的成功标准是“在长程目标任务中的整体达成率”中间调用了多少次工具、有没有走弯路、遇到异常有没有自我修复每一项都影响最终判断。论文圈子的演进其实一直在暗中呼应这条路径。Toolformer时代的思路还是“让语言模型学会使用工具”本质上仍然是把工具当作外挂计算器到了ReAct论文首次把推理轨迹和行动交错起来让模型边想边做、根据环境的反馈修正下一步这才真正出现了“感知-行动闭环”的雏形再到Reflexion干脆让Agent在失败后基于语言反馈做自我反思把上一次错误转化成下一次尝试的经验。AutoGPT和BabyAGI在2023年火过一阵但工程上翻车极多核心原因也是它们只搭了一个“循环调用”的外壳没有把状态、边界和恢复机制做实。后来WebArena、OSWorld这类环境型评测集出现是一件标志性的事情社区对Agent的关注点从“模型会不会答”彻底转向“模型能不能在模拟环境里完成任务”。这个转向就是范式跃迁最直观的证明。下面这张表是我自己整理的一套判断框架拿来评估一个系统是工具还是Agent或者是“披着Agent外衣的工具”维度工具型系统伙伴型Agent系统行为模式指令-执行-返回目标-感知-决策-行动-反省状态管理无状态或短会话状态跨任务持久化记忆交互频率一次请求一次响应多轮闭环直到目标达成或中止成功标准单次响应是否正确长任务是否整体达成失败模式确定性报错路径偏差、幻觉、死循环、半途而废排查方式看日志定位错误看轨迹回放分析决策过程测试策略单元测试接口回归评测集轨迹评估风险护栏测试如果一个项目还在用单轮问答的指标去衡量一个多轮Agent那后续所有工作都会拧巴。我见过一些团队拿着准确率90%的问答指标出去汇报Agent进展实际上他们的系统根本不会自主行动只是把用户问题接进了一个带工具的聊天接口。这不算错但千万别把它叫Agent。2. 架构基座感知-决策-行动闭环是Agent和普通接口的分水岭“从工具到伙伴”如果在架构上找一个落点那就是ReAct循环。不管外面包装多少层框架、多少种记忆机制最底层那个循环永远是四个步骤感知环境状态、基于当前状态做决策、执行一个行动通常是调用工具或输出回复、观察行动带来的反馈然后回到决策环节直到任务结束。2.1 ReAct循环在工程里长什么样用一个伪代码来表达这个循环比几百字描述更直接task parse(user_goal) state init_state() while not task.is_finished(): observation gather_observation(state) action llm.decide( system_promptagent_prompt, contextstate.context_window(), observationobservation, toolsavailable_tools(), ) if action.type call_tool: result execute_tool(action.tool, action.args) state.add_step(action, result) elif action.type reply: output(action.message) break elif action.type ask_human: feedback wait_user(action.question) state.add_feedback(feedback)这个循环看起来很简单我见过一百个Agent项目的核心都是这个。差别在哪差别在循环以外那些“看不见的东西”——循环断了怎么续、上下文满了怎么压缩、工具报错是重试还是放弃、同一个任务在两次执行之间状态存在哪里。很多团队把Agent写成了单进程里的死循环Task结束后状态就地丢弃一旦中间进程重启整个任务就归零。这在Demo里没问题在真实产品里就是事故。工业级Agent的任务编排必须是一个持久化的状态机每一轮决策、每一次工具调用结果都要落盘任务才具备断点恢复的可能。2.2 harness与Agent的区别这里混了后面全乱很多人在选型时搜“harness和Agent区别”说明这个话题确实让人困惑。我给出一个自己的定义Agent是决策主体是那套“感知-决策-行动”的策略harness是Agent赖以生存的执行环境包括工具注册表、权限控制、上下文装配管道、记忆系统、生命周期管理、可观测性和恢复机制。做个不恰当的类比Agent是驾驶员harness是整辆车。驾驶员负责判断往哪开车负责提供动力、转向、刹车、仪表盘、安全气囊和事故后的救援通道。你换一个更好的驾驶员车况不好照样翻车你给车装上顶级的悬挂驾驶员不会判断路况也白搭。工业界大量Agent项目“重模型轻harness”System Prompt写得天花乱坠工具列表放了一堆但执行侧连最基本的可观测性都没有。Agent调用了哪个工具、传了什么参数、中间哪一步开始偏离预期全部是黑盒。这种系统上线后就是定时炸弹。近期很多厂商开始推“Agent Skill”体系本质上也是为了解决harness层的问题——把Agent可用的能力封装成显式的、可复用的、可动态装卸的技能单元每个技能包含触发条件、调用方式、需要的上下文、输出约定。这个思路是对的它把“能力边界”从模糊的Prompt暗示变成了结构化的harness配置。做Agent开发时尽早把能力边界显式化比事后靠模型自觉要靠谱得多。2.3 上下文治理无限任务塞进有限窗口所谓长上下文并不能解决Agent生产环境里全部的上下文问题。理论上清华的小羊驼都能处理几百万token但工业界的成本模型和时延模型都撑不住“每轮决策都把全部历史塞进去”。ReAct循环里每一轮推理都要携带历史上下文窗口的增长是指数级成本压力。工程上更务实的路径是三层配合工作上下文只保留当前状态摘要和最近几步的关键结果外部存储保存中间过程的完整细节需要时按需检索更早的历史做压榨式摘要沉淀为长期记忆条目。这和人类写代码时的习惯是一回事——不会每次把手头所有文件内容贴进脑子而是只关注当前栈帧需要时再展开调用栈。我的一个实操经验是给Agent的上下文做“预算”。每一轮决策前明确当前任务内存放什么、工具结果里哪些字段进上下文、哪些只落日志。这比直接堆长上下文省钱得多迭代时也能更快定位是哪一步污染了决策质量。2.4 任务状态与并发模型为什么Agent扛不住并发“AI Agent怎么扛并发”是搜索热词但大家问这个问题时脑子里想的往往还是传统接口的并发——每秒来多少个请求。Agent的并发模型跟这个完全是两码事。一个Agent任务的平均时长不是几百毫秒而是几十秒甚至几分钟期间要多次调用LLM、调用工具、等待外部系统响应。所以并发度不是“同时能处理多少请求”而是“同时有多少个长时任务在活跃”。如果平均任务时长90秒一个任务平均调用10次LLMLLM侧配额是每分钟600次请求那系统能同时支撑的活跃任务数大概是600÷10×1.590个1.5是单位换算系数600次/分钟×90秒/60秒900次900÷1090个任务的理论上限再留一些重试余量就得打折。这意味着服务端必须引入任务队列、状态存储和异步worker而不是简简单单挂一个HTTP接口同步等Agent跑完。很多团队第一步就错在这里用同步语义去做长时任务前端等到超时后端进程不断堆积最后整个服务被打挂。长时任务必须要用“提交任务-查询状态-回调通知”的异步模式并且对每个任务设置最大轮数和总时长上限防止Agent进入死循环烧钱。3. 多Agent协作的工程真相协议比Agent数量更值得花时间“多Agent”可能是Agent领域被误解最深的概念。很多人以为让两个Prompt互相发消息就是多Agent协作实则不然。多Agent的价值不在于“多个大模型在聊天”而在于把不同类型的能力、权限、责任边界拆分到不同执行单元里再通过协议组织起来。核心问题不是造出多少Agent而是Agent之间怎么通信、怎么路由、怎么裁决。3.1 什么时候真需要多Agent我判断一个业务是否需要多Agent只看三个信号第一任务需要不同权限边界。比如一个Agent负责写代码并执行另一个Agent只负责Review代码两者不能共享全部权限。拆开是安全需求不是炫技。第二任务存在天然的对抗复核关系。一个人既当运动员又当裁判错误很难被拦住。所以代码生成和代码审计、SQL编写和SQL校验天然适合两个角色协作的模式。第三任务可以并行分块。比如市场分析中数据收集、舆情扫描、报告起草互不依赖拆开并行能显著缩短总耗时。这种情况下拆多Agent是性能需求。拿代码场景举例。我个人实践下来的分工是Agent A负责按任务描述写代码并执行测试Agent B只拿代码文本和测试结果做Review发现A忽略的边界条件、错误假设和危险操作。这两个Agent的System Prompt差异很大工具权限也不重合协作协议里明确约定“B认为有风险时任务回到A进行修正最多往返两轮”。这套设计比单个Agent反复“反思”自己要可靠——反思容易陷入同一个思维盲区而独立的评审视角能有效打破它。3.2 两种编排模式的取舍多Agent的组织方式工业界最主流的就是两类。一种是Orchestrator-Worker模式也叫中心化编排。主Agent负责拆解任务、分派给子Agent收集结果并做汇总。特点是全局状态在主Agent手里子Agent不掌握全局只能处理分内的子任务。优点是控制力强、故障隔离好、容易审计缺点是主Agent可能成为瓶颈且整体复杂度受限于主Agent的规划能力。另一种是Chat-based模式类似AutoGen那种去中心化的对话式协作。Agent之间直接对话、协商、互相提问组织形式更灵活适合探索性和开放式任务。但它也是一把双刃剑全局状态分散在各个Agent的私聊里一旦对话轮次变多很难追踪是谁在基于哪个信息做了决策而且Agent之间可能陷入互发消息的死循环Token消耗完全是失控状态。生产环境里我几乎只用Orchestrator-Worker模式。原因很简单可控性和可观测性优先于“智能感”。客户可以接受一个Agent做错事但不能接受一个Agent系统出了问题后连“是谁、在哪一步、基于什么做的决定”都说不清。3.3 生产选型框架在Agent工程里的真实地位现在Agent框架一抓一大把LangGraph、AutoGen、CrewAIJava生态有Spring AIRust社区也有一些开源harness实现。我个人的选型视角不是“哪个智能”而是“哪个能在生产环境让我睡得着觉”。LangGraph适合喜欢精细控制状态流转的团队它是用图结构定义Agent的状态机节点、边、条件分支都显式可配对长任务编排和恢复支持比较成熟。AutoGen更适合快速做多Agent对话式原型上面说过对话式协作上生产要额外付出很多管控成本。CrewAI对“角色扮演式”的多Agent协作更顺手但内部机制封装较深真出问题排查起来相对费劲。Spring AI的定位则很清晰——如果你的技术栈已经在Java/Spring里用它统一集成大模型、工具调用和Agent编排学习成本和运维成本都低。我们团队也有同事尝试用Rust重写Agent执行层追求更低的资源占用和更强的隔离性这个方向可行但前提是你的团队有比较强的系统工程能力。框架只是脚手架真正决定成败的还是我们前面说的那几个工程问题状态、上下文、工具边界、恢复和评测。3.4 协作护栏没有护栏的多Agent是火灾多Agent系统设计时必须给协作加上几道护栏否则它不是为你工作而是在烧你的预算。第一道护栏是最大交互轮数。Agent A和Agent B之间没有限制地互相反馈一定会出现来回扯皮。我给每个Agent对设置独立的轮数上限超了就上报主Agent由主Agent决定是终止、换策略还是转人工。第二道护栏是Token预算。大模型调用按Token计费多Agent的Token消耗是乘数级上涨。我在任务开始前就给全局预算分配额度——这个任务的每个环节最高能花多少Token超了就触发降级从“自主推理”降级为“直接调检索工具”。第三道护栏是冲突裁决。子Agent意见不一致时比如代码评审Agent认为有风险开发Agent认为没问题必须有明确的裁决机制。在Orchestrator模式下这个裁决权在主Agent如果主Agent也拿不准就转人工。最忌讳的是让两个Agent无限协商下去这不是智能是死锁。4. 沙盒、安全与长任务恢复扛住并发的先决条件Agent的系统要上生产绕不开三个让人头疼的词沙盒、安全、恢复。热搜词里“codex无法发送消息显示更新agent沙盒”“agent沙箱”频繁出现说明这些问题不是理论层面的而是每天都在发生的真实事故。4.1 Agent沙盒为什么是必选项Agent有了工具调用能力之后就不再是“只能说话”的聊天机器人了。它能执行代码、读写文件、发请求、操作数据库。这意味着一个幻觉或者一次提示注入就能造成真实世界的破坏。沙盒的作用很简单把Agent的能力限制在受控边界内让它“什么都能做但只能在笼子里做”。沙盒的落地方式取决于风险等级。低风险场景用受限的运行时和网络白名单就够了中风险场景需要容器级隔离每个任务跑在独立容器里网络、磁盘、内存全部受限高风险场景比如Agent直接操作生产环境要上更严格的审批流、双重确认和全量审计日志。这里有个工程细节容易被忽略沙盒的生命周期管理。沙盒不能是“用完即弃的一次性玩具”它要像虚拟机一样管理——创建、回收、快照、迁移、清理。每个Agent任务开始时分配沙盒任务结束或异常退出时回收沙盒同时保留任务相关的快照供事后排查。Codex用户在高峰期看到“沙盒更新中”“无法发送消息”这类提示背后往往就是工作区在扩容、迁移或重建说明沙盒层的运维和Agent编排必须连成一体而不是两个割裂的团队各自为政。4.2 提示注入Agent安全的头号敌人传统API调用的安全模型里输入输出边界很清晰。Agent不一样它会读网页、读邮件、读文件这些外部内容里可能藏着恶意指令——这就是提示注入。更麻烦的是Agent在长时间任务中会把工具返回的结果重新组装进下一轮决策的Prompt里如果工具返回的内容被污染Agent就可能在不知情的情况下执行攻击者指令。工业界的常规做法是三层防御第一层输入内容进入Prompt之前必须做中性化处理外部数据网页内容、文档文本和指令性内容System Prompt、工具定义放在完全隔离的上下文区域禁止指令区域被外部内容动态改写第二层Agent要执行敏感动作删除、转账、发送消息时必须独立确认不能把“工具返回值”和“用户真实指令”混在一起触发危险操作第三层所有工具结果全部记录审计日志一旦发现异常指向可以回溯是哪一步被污染。4.3 幂等与任务恢复长任务的救命稻草Agent任务动辄几分钟网络抖动、模型超时、worker重启发生的概率是百分百的。只有设计好“失败后怎么办”Agent才真正算工业级。我强烈建议给Agent的每一次工具调用都加上Request ID和幂等键。这个习惯越早养成越好。比如一个Agent要调用支付接口如果第一次调用超时了但实际扣款成功重试时没有幂等键就会造成重复扣款。具体操作是每次调用工具时生成一个幂等键服务端保存该键与执行结果的映射重试时带上同一个键服务端先查是否已处理过已处理就直接返回原结果。任务恢复则要分层设计进程级恢复靠状态持久化每次决策和工具调用结果都写状态库worker崩溃后从最近一个稳定状态重启业务级恢复靠快照机制把上下文窗口、任务进度、已完成步骤一次性承接过来让Agent从上次中断处继续。没有这套机制长任务并发做得越好翻车越惨。5. 评测集与回归体系没人敢用不可度量的系统Agent的评测问题是工业界真正的分水岭。传统软件有单元测试、集成测试、端到端测试Agent系统跑了一堆功能最后怎么证明它是好的答案只有一个评测集。但Agent评测集的构建方法和传统测试完全是两回事。5.1 为什么单元测试在Agent这里失灵单元测试的全部意义在于“给定输入断言输出”。但Agent的行为是非确定性的同一个任务两次运行可能给出不同的工具调用顺序最终结果也可能不同更关键的是Agent系统的价值不在于某一句话说得对不对而在于整个任务过程是否合理、目标是否达成、遇到意外是否处理得妥当。如果你只关心最终输出的文本等于无视了Agent全部的过程智能。所以Agent评测不叫“测试”叫“评测集”。它不是断言单个输出而是评估一系列行为轨迹。5.2 评测集怎么建从采样到分层标注我的建议是四个步骤缺一不可。第一步从线上真实会话中脱敏抽样。不要只在受控的Demo场景里造数据真实用户的表述千奇百怪中途改需求、给信息不全、情绪化表达这些才是评测集宝贵的部分。第二步人工分层标注。每个样本至少要标注四个维度任务是否最终完成、完成路径是否合理、工具调用是否正确且高效、有没有出现危险或违规操作。标注是累活但这是评测集的立身之本别偷懒用纯自动标注替代。第三步难度分层。评测集不能全是简单任务一定要保留相当比例的长程复杂任务和多步工具调用场景。只有easy样本的评测集模型的得分再高也没有参考价值。第四步沉淀回归基线。每次改Prompt、换模型、调整工具定义都用同一套评测集跑一遍对比新旧版本在任务完成率、平均工具调用次数、无效重试次数等指标上的变化。没有回归基线你根本不知道一次改动到底是优化还是退化。5.3 指标怎么选任务成功率远远不够任务成功率是最基础的指标但不能只看它。举几个失败的例子光看成功率完全体现不出来一个Agent可能用20次工具调用笨拙地完成了一件5次就能完成的活成功率100%但每个任务的Token成本和时延高得吓人。另一个Agent可能成功率不错但出现过一次危险操作——这是必须被一票否决的。我的建议是至少盯住五个维度任务成功率、平均工具调用步数、关键错误率比如幻觉参数和危险操作、无效重试次数、用户放弃或人工介入率。其中“人工介入率”是最容易被忽视但最敏感的指标。当一个Agent系统需要频繁人工干预时说明它的自主性不达标反过来如果人工介入率长期为零也别高兴太早可能只是说明它做的任务太简单。合理区间因场景而异但必须持续监控它的走势。5.4 模型升级不是“升了就完事”模型升级是这个领域最刺激的翻车现场。模型能力变强不代表Agent系统变好——新版模型可能更聪明也可能更“自作主张”更爱编造不存在的工具参数或者更不爱遵循你的指令格式。任何模型升级都要执行一次双跑对比旧的评测集、旧的和新的模型同时跑一遍逐项对比。工具变更同样如此你改了一个工具的输入输出schema所有依赖这个工具的Agent任务都要在评测集上重新验证一遍。评测集是Agent系统唯一不会骗你的东西这句话我希望每个读者都记在工位上。6. 记忆分层与个性化让Agent从“会做事”到“懂你”的落点“Agent记忆”一直在热搜里但我发现很多人对记忆的理解仍然停留在“加一个向量数据库”的层面。真要把Agent做出一副“伙伴感”记忆体系至少要拆成三层。6.1 三层记忆模型工作记忆对应任务执行过程中的动态上下文就是当前Agent正在处理的事情——刚才调了什么工具、结果如何、下一步打算是什么。这部分状态短、内容杂、更新频率高放到状态库里或Redis里就行。情景记忆对应跨会话的历史交互比如用户上次委托过一个数据分析任务、当时他偏好用月报视角而不是日报视角、上次任务卡在哪个环节。这部分是让Agent“越来越懂用户”的关键通常存向量库按语义相似度检索。语义记忆对应关于用户偏好和项目背景的长期稳定知识比如“用户所在团队是电商方向”“用户偏好保守风格的设计”“用户对数据隐私非常敏感”。这部分更适合结构化的配置文件而不是向量检索因为它是高精度的、需要直接引用的信息。6.2 RAG不等于记忆把RAG当成记忆是个经典误区。RAG解决的是“外部知识检索”的问题它回答的是“相关内容在哪里”记忆解决的是“系统内部状态和行为偏好积累”的问题它回答的是“用户和项目之前发生过什么”。两类技术可以结合使用但目标不同。工业界很常见的一个错误是把用户的长期偏好也丢进向量库做相似度检索——结果就是Agent时而记得、时而不记得还容易检索到相似但不相关的偏好片段造成行为不一致。用户对你的Agent最直接的“伙伴感”来源就是行为一致性这次知道的事下次不用再重复一遍。向量检索天然不保证一致性所以关键偏好必须结构化保存。6.3 落地记忆的轻量方案如果你的Agent项目还没到特别复杂的规模我建议不要一上来就上重型记忆系统。一个轻量但完整的方案是三条线结构化配置表存用户偏好和项目常量每次组装System Prompt时直接注入历史摘要向量库存每次会话结束后生成的摘要按需检索最近相关话题事件日志存所有关键动作和决策记录用来做历史回溯和反思。这样一套组合能让Agent在人机对话里表现出三个非常可贵的品质记得住上次的偏好、接得上上次的话题、解释得清上次的决定。这正是“从工具到伙伴”最直观的用户感知。在写第一篇的结尾我想说点实际的体会。我见过太多团队一上来就冲“多Agent长期记忆全自主”的宏大架构结果连单Agent任务闭环都没跑稳。如果你现在正在起步我的建议是把顺序反过来先把一个场景的感知-决策-行动闭环做扎实给所有工具调用加上幂等键把评测集的第一版建起来再谈多Agent协作和记忆体系。范式跃迁的落地从来不是模型单点突破而是工程体系的整体升级。最后再分享一个实操小技巧给Agent的每个决策步骤都打一个结构化日志字段——步骤ID、父步骤ID、意图类型、工具名、输入摘要、输出摘要、Token消耗。这个习惯会让后续所有调试、评测、成本分析省下大量时间。系列第一篇先到这里后面我会继续展开每个主题的实战细节。