★ FEATURED ARTICLE 1. 为什么说Agent的伙伴化是一次系统级的重构过去一年我密集做了两件事把Agent方向的代表性论文过了一遍同时在几个真实业务场景里把Agent从Demo推到上线。两件事合在一起最强烈的感受是当前讨论的Agent绝大多数还停留在工具层面——让模型学会调API、返回JSON然后用一段for循环串起来。而论文里讨论的、以及用户内心真正期待的已经是伙伴层面的东西。从工具到伙伴的范式跃迁不只是一句产品口号它意味着系统架构、交互方式、失败容忍度和安全边界全部要重新设计。1.1 从函数调用加循环到目标驱动自主行动先定义一下我理解的工具和伙伴的区别。工具形态的Agent本质上是Function Calling加一个循环。用户把任务拆成一步步指令查这个字段、跑那条SQL、把结果填进表格。模型每一步都听指令执行程序在外部用循环把步骤串起来。这种形态在信息抽取、结构化查询等场景里非常成熟好处是可控性很强出了问题能立刻定位到具体环节。我的第一个Agent项目就是这么做的效果不差但一直被业务方吐槽不像智能像个按键精灵。伙伴形态的Agent核心变化是目标驱动。用户只给一个最终目标比如帮我把最近三个月各渠道的投放转化率整理成报告标出异常波动给出原因分析。Agent要自己决定访问哪些数据源、先做什么后做什么、中途发现数据缺失时怎么补救、最后还要对交付结果负责。整个过程中模型不再是一次性回答问题的聊天引擎而是一个有状态、有记忆、能试错、能自我修正的执行体。这两者表面看只是自动化程度不同落地时差距却是系统级的。工具形态的失败是局部的某个API调用失败重试一次就行。伙伴形态的失败是全局的Agent在第三步做了一个错误决策可能导致第八步的最终结果全错而且错误链条很长用户很难定位。所以我在做第二个项目时强制自己换了一套设计思路不是先想这个需求要调哪些接口而是先想这个Agent在什么约束条件下可以自主到什么程度。这个决策顺序直接决定了后面所有的架构选择。1.2 伙伴化带来的架构与信任模型变化伙伴化的代价是系统不再是一个输入输出确定的函数而是一个有限状态机甚至是一个长期运行的服务。这里有三个我在Demo里很少见到、但生产环境绕不开的变化。第一状态与记忆成为一等公民。工具调用前后可以无状态但伙伴必须记住对话上下文、任务进度和用户偏好。这意味着要引入外部存储、上下文压缩、记忆摘要而不是把所有东西都塞进Prompt。Prompt总有一天会撑爆而记忆机制不会。第二失败策略从报错变成补救。工具时代接口报错就返回错误信息由人来兜底。伙伴时代Agent必须判断这个错误是否影响最终目标能不能换一条路径继续。比如数据库查询超时是重试一次还是切换只读副本还是降低查询粒度这类应急策略必须预先编码进系统不能指望模型每次都临场发挥。第三信任模型变了。用户开始把一部分决策权交给AgentAgent就必须提供足够的透明性和可干预性。我的做法是让Agent的每一步关键决策都以建议卡的形式反馈给用户用户可以选择执行、修改或叫停。一开始同事觉得这样太啰嗦但实际跑下来用户对可以被中断但总体可控的Agent接受度远高于黑盒一步到位的Agent。这个阶段的差异我用一张表总结过后来直接成了项目方案评审的一页纸维度工具形态伙伴形态用户角色把任务拆解并逐步指挥只给目标过程由Agent推进状态管理无状态或短状态长任务状态、持久化记忆失败处理局部报错重试全局补救、路径切换关键指标接口正确率任务完成率、用户介入次数安全边界按接口授权按目标授权需要沙箱与审计记住这张表后面每一节的内容都能在里面找到落点。2. 论文脉络里藏着范式跃迁的完整证据链如果你只看最新几篇Agent论文会觉得这个领域是被ChatGPT带火的。但把时间线拉长看从工具到伙伴的跃迁在论文里有一条很清晰的演进逻辑先让模型学会使用工具再让模型在行动中推理接着让模型从反馈中修正自己最后让模型在长周期里保持记忆和协作。2.1 ReAct到Reflexion推理、行动与自我修正Chain-of-Thought刚出现的时候本质上是在增强模型的思考能力但思考完就直接给答案没有行动环节。ReAct这篇论文的贡献在于把思考Thought和行动Action交替进行模型先想一步然后调一个工具看到观察结果Observation再继续想。当时读这篇论文我有一个很直接的反应这才是Agent该有的样子而不是让模型干想。紧接着Plan-and-Execute把规划从执行中分离出来。Agent先通过一次推理生成一个完整的计划列表再逐步执行。这种设计牺牲了一点灵活性但换来了极高的可读性和可干预性。用户可以在计划阶段修改方向而不是等Agent已经跑完五步才发现路线错了。直到今天我仍推荐大多数业务场景优先采用这种结构因为计划列表本身就是最天然的人机交互界面。再往后Self-Refine和Reflexion把反馈-修正做成了显式循环。Self-Refine的思路很朴素让同一个模型先生成一个结果再给自己打分提出修改意见再重新生成。Reflexion更进一步把失败经验写进了一种类似情景记忆的缓冲区下次遇到类似情况时先翻旧账避免重蹈覆辙。还有一篇值得单独说的是SWE-agent论文。它最大的启发不是在模型侧而是在环境侧论文提出了Agent-Computer InterfaceACI的概念意思是Agent不是直接面对终端而是面对一套为它精心设计的界面和命令。换句话说Agent聪明与否不只看模型还看你给它搭的环境顺不顺手。这个观点我太认同了后面讲Harness和框架选型时会再展开。2.2 记忆与多Agent从单次对话到持续协作论文演进到这里单个Agent已经能在一次任务里完成思考-行动-修正的闭环但距离伙伴还差两个关键能力长期记忆和群体协作。记忆方向MemGPT是绕不开的。它把操作系统里的虚拟内存概念搬到了LLM上下文中短期的对话内容相当于内存长期的重要信息换页到外部存储里需要时再调回来。这套机制解决了我实际项目中最大的痛点——上下文窗口再大也装不下一个持续数周的项目过程。同样值得关注的是记忆摘要的做法不是把原始对话全部存进向量库而是每隔一段对话就生成结构化的摘要作为长期记忆写入存储。这一点我在第5节会讲具体的工程实现。多Agent协作方向上AutoGen、MetaGPT、AgentVerse这些工作各有侧重。AutoGen强调的是对话驱动的多Agent协作Agent之间通过自然语言来回讨论MetaGPT像一家软件公司让产品经理、架构师、工程师角色分工协作AgentVerse则更关注群体行为涌现。这些论文给工业界的信号是复杂任务可以拆给多个专精Agent而不是让一个全能的Agent硬扛。但我必须泼一盆冷水多Agent不是银弹。团队协作本身会带来通信开销、决策冲突和错误传播三个LLM互相甩锅的场面我见过太多次。工业落地时绝大多数场景一个Agent加一个高质量的工具栈就够了。多Agent应该是最后的手段而不是最开始的设计。论文里的惊艳效果大多建立在精心构造的评测集上和生产的混乱环境不是一回事。3. 工业落地的第一课要把会跑通变成跑得稳论文里Agent可以在精心构造的例子上跑通但工业界要的是在整个任务空间里稳定跑到80分以上。这个差距几乎是两个工种。我在生产环境里摔了半年跟头总结下来最核心的就是三件事状态、幂等与可观测性。3.1 状态、幂等与可观测性生产环境的三座山先说状态。一个Agent任务可能持续几分钟甚至几小时用户中途刷新页面、断网、甚至关掉电脑任务都不应该丢失。所以我从一开始就放弃把Agent状态放在进程内存里强制要求所有状态写入外部存储。每个任务有一个task_id每执行一步就把当前进度、已生成结果、下一步计划完整保存下来。用户重新打开页面时直接从存储恢复现场而不是重新跑一遍。然后是幂等。Agent的工具调用本质上是外部副作用如果网络超时后重试很可能造成重复扣款、重复建单、重复写日志。我和团队定了一条铁律每个工具在接入前必须回答三个问题——这个调用可以重复执行吗如果不能怎么保证只生效一次如果外部系统不支持幂等要不要在前置环节做去重没有答案之前这个工具不允许进Agent的工具箱。可观测性则是我吃过亏之后才补上的。第一次上线时Agent出错我只能看到一句抱歉我遇到了一些问题没有任何中间链路业务方又提供不出复现步骤最后只能靠猜。后来我把体系补完整每一个Thought、每一次Tool Call的入参和出参、每一步的token消耗、每段对话的延迟全部落trace日志。现在排查问题的方式变成了打开trace找到出错那一步直接看当时的上下文和外部返回效率完全不是同一个量级。3.2 AI Agent怎么扛并发别只盯着加机器这个热搜问题当时也困扰了我很久。先给结论Agent扛并发真正的瓶颈往往不在GPU而在LLM接口限流、外部依赖限流和状态管理的并发安全。LLM接口的TPS是硬上限。你算一下单任务平均要调多少次模型再乘上并发任务数很快就触顶。我的方案是三层叠加任务队列削峰、令牌桶控制自身调用速率、退避重试机制应对限流。这里可以给一个Worker侧的简化伪代码实际上我们生产就是这么跑的def run_agent_task(task_id: str, goal: str): state load_state(task_id) # 从Redis/PostgreSQL恢复状态 while not state.is_finished: action agent.decide(state) # LLM Planning result execute_tool(action) # 工具调用内置超时和重试 state.append(step, result) # 追加步骤记录 save_state(task_id, state) # 每步都持久化崩溃可恢复这套架构的核心思路是Worker本身无状态所有状态都在外部存储里取任务可以是多个Worker的。Redis Streams或Kafka都行重点是任务不会因为Worker崩溃而丢失。另外在DAG编排层我会把没有依赖关系的工具调用并行化例如同时查三个数据源而不是串行排队这一步能省掉将近一半的等待时间。还有一个容易被忽视的细节熔断和预算控制。每个Agent任务要有一个硬性的步骤数上限、token上限和耗时上限超过就强制终止并转入人工处理。否则一个失控的Agent会在半夜把整个供应商的额度全部烧光。这个我踩过真坑成本账单出来的时候整个人都清醒了。4. 从LangChain到自研编排框架、Harness与真实选型框架选型是每个团队都避不开的问题。市面上的选择实在太多但很多人搞混了一个概念Agent框架不等于Agent本身。我习惯把技术栈分成三层来看。4.1 框架分层LLM调用、编排层与运行时第一层是LLM调用层处理模型接入、API密钥、流式输出、token计费这些基础能力一般用LangChain的Model I/O或者各家官方SDK就能解决。第二层是编排层负责设计Agent的行为逻辑走ReAct循环还是Plan-and-Execute用什么图结构组织步骤哪些节点可以并行哪些节点是终止点。LangGraph是这一层的典型代表它把Agent流程显式建模成状态图节点和边都由开发者控制比LangChain早期的AgentExecutor黑盒透明得多。第三层是运行时层指的是部署、状态存储、并发调度、安全沙箱、审计日志、评测系统这些生产基础设施。现在很多团队在编排层耗费大量时间结果到了生产环节才发现运行时空空如也什么都要自己补。这三层分开看很多争论就不那么重要了。不是说用了LangChain就一定不好而是你要清楚它在哪个层帮助了你、哪个层仍然需要你自己建。4.2 Harness与Agent到底什么关系选型时怎么判断Harness这个词在这两年频繁出现但很多人的理解是模糊的。简单说Harness是围绕Agent设计的一整套运行环境包括输入输出约束、工具注册机制、记忆管理、循环控制、终止条件等。Agent模型在Harness里生成推理和行动Harness负责把行动落到真实世界再把结果反馈给模型。SWE-agent论文里提到的ACI就是一个典型的Harness设计思路不给模型一个纯终端而是给模型一套精心设计的交互命令让模型更容易完成代码修改任务。当时我受到的触动是与其指望模型在糟糕的界面里灵光一闪不如花力气把界面本身设计得对模型友好。所以Harness和框架的区别是什么框架更多提供通用编排能力而Harness更关注Agent与环境的完整交互协议。你在选型时可以这样判断如果业务需要深度控制工具的输入输出规范、记忆管理方式和风险控制逻辑那本质上你需要的不是换框架而是搭自己的Harness。市面上的框架可以成为底座但最终这一层大概率要自己做大量定制。4.3 我在两个项目里的框架选型复盘第一个项目是知识库问答客服Agent属于典型的文档检索生成场景。我用了LangGraph原因是流程足够清晰意图识别、召回、重写、生成、引用校验每一个节点都固定图结构天然适合。LangGraph的显式状态让我们能清晰地看到每一步的输入输出调试成本比之前用AgentExecutor低了一个量级。第二个项目是数据库分析Agent要接十几个数据源、执行动态生成的SQL、并生成可视化结论。这个场景业务规则极重安全要求极高SQL执行不能直接放给模型自由发挥。最终我们选了自研编排用一张工具注册表管理所有数据源的权限、限流、白名单和审计用一版Strict JSON协议控制模型输出的结构化字段再用一个状态机管理查询、纠错、汇总的流程。自研确实多花了三周时间但换来了对高危操作完全可控的安全机制这笔账是划算的。顺带说一句低代码平台。Coze和Dify这类平台在快速验证和内部工具场景很好用非技术同事拖拽配置就能做出一个不错的Bot。但如果要嵌进核心业务链路、处理长事务、对接复杂权限体系这类平台的定制成本会很快超过重写一个编排器的成本。我的建议是原型用平台生产自建底座不要一开始就把核心链路押在一个不可拆分的平台上。5. 记忆、技能和安全把伙伴做扎实的三个底线工程范式跃迁从口号变成现实最终要靠三个底层能力支撑记忆让Agent有连续性技能让Agent有行动力安全让Agent可被信任。这三块任何一块缺位伙伴都是空中楼阁。5.1 Agent记忆的工程实现不是塞个向量库就行很多人一说到Agent记忆第一反应是用向量数据库存历史对话。这个思路试过之后会发现远不够原始对话直接塞进向量库召回时噪声大、存储浪费、隐私也难处理。我现在的方案是三层记忆配合使用。第一层是工作记忆相当于Agent当前正在处理的短期上下文比如正在分析的一份报表、正在生成的一份报告中间稿。这一层会被持续压缩避免上下文无限膨胀。第二层是情节记忆每次任务结束后把这段对话转成结构化摘要包括用户的目标、偏好的表达方式、最终方案、还有用户纠正过的地方。第三层是语义记忆沉淀关于用户和业务的事实性知识比如用户是市场部最关注ROI口径。每次生成记忆记录时我会额外打上重要性分数和来源ID方便去重和更新。举一个实际会存下来的记忆片段{ type: preference, content: 用户偏好日报格式先汇总数字再列异常最后给建议。, source: conversation_20241108, importance: 0.8 }这套机制的核心价值不只是让Agent记得用户叫什么而是让它在几周后再次处理同类任务时能直接调用上一次沉淀的方法论。这才是伙伴和搜索引擎的差别。5.2 Skill与工具注册给LLM一把用着顺手的螺丝刀工具管理是这个领域最容易被低估的工程。很多人以为工具注册就是把函数名和参数定义放在Prompt里让模型选但实际生产里远远不够。我把工具的注册元数据设计成了一套完整的说明书名称、一句话描述、参数Schema、使用场景、典型范例、错误提示和权限等级。描述写得越准确模型越能正确选择工具。这里有个真实案例一开始我们的工具描述写的是query_campaign_data查询Campaign数据模型经常把它用错到别的数据源上。后来改成query_campaign_data查询市场投放活动中各渠道的曝光、点击、消耗与转化数据适用于垂直维度拆解和趋势分析数据源为ad_platform误用率直接下降了一半以上。比工具更高一层的概念是Skill技能。工具是原子操作但Skill是把多个工具组合成一个可复用的子流程比如生成周报这个Skill内部要依次做数据拉取、异常检测、文案生成、图表生成、格式排版。把这类高频动作沉淀成Skill效果有两个一是Agent决策次数减少错误率下降二是企业的方法论被固化进了系统新人上手成本大幅降低。还是一条铁律不要把所有工具一次性暴露给模型。工具越多选择错误率越高。按任务类型动态装配工具集比一个超大的工具列表可靠得多。5.3 安全边界越是自主越要限制权限Agent能访问的数据和执行的操作越多安全设计就越要从按接口授权转向按目标授权。我在这块建立的底线模型有三层。第一层是权限最小化。数据库Agent默认只读文件Agent默认只访问指定目录邮件Agent默认只能发送给白名单内的地址。宁可多配置几个角色也不要让一个Agent拿到全局读写的钥匙。第二层是沙箱与隔离。所有可能在外部产生副作用的代码执行比如生成SQL、执行脚本、写文件都放在受控的沙箱环境里禁止直接触碰生产核心系统。即使Agent的Prompt被注入攻击它也只能在沙箱里造成有限影响。第三层是高风险操作的人工审批。删除数据、发送消息、修改配置这类动作Agent只能生成指令真正执行前必须经过授权人或授权系统确认。这一点对伙伴感有没有损伤确实有一点但用户的原话是慢一点没关系但别让Agent自己把事搞砸。安全是信任的基础没有信任伙伴就只是个危险的玩具。所有工具调用我都要求留存完整审计日志谁在什么时间通过哪个Agent执行了什么操作、耗了多少成本都要能回溯。这个要求听上去繁琐但一旦出问题它能救整个项目。6. 评测与灰度工业界最容易被低估的一环我在内部做过一个调查很多Agent项目死在Demo很惊艳生产没人敢用核心就两个原因不知道好不好不敢直接上。评测和灰度就是解决这两个问题的。6.1 Agent任务没有标准答案怎么定指标传统AI任务有标准答案ACC和F1一算就行。Agent任务是开放式的同一个目标可能有多种正确路径这就要求评测体系从答案是否正确转向过程是否有效、结果是否可接受。我目前实际在用的指标组合包括任务完成率Agent最终是否达成目标且结果被用户确认、工具调用成功率所有Tool Call中成功比例、决策路径有效率每一步是否为最终结果作出了贡献、用户介入次数用户打断或纠正的次数越少代表Agent越省心、以及单任务成本token和耗时。需要说明的是光有一个完成率数字远远不够。我们的离线回归集是从真实用户会话里抽出来的一批高频任务样本每次改完Prompt、换完模型或调整编排结构后都要在回归集上跑一遍对照这些过程指标是否回退。这个回归集就是Agent项目的单元测试没有它所有优化都是在蒙眼开车。6.2 影子模式、线上反馈闭环与灰度策略评测集做得再全也覆盖不了线上长尾场景。所以上线策略我坚持走影子模式Agent先接到真实流量但它生成的决策和结果只记录、不执行或者以建议形式展示给用户。系统后台把Agent的表现和用户实际行为做对比积累一个真实的如果当时由Agent接管结果会怎样的样本池。影子模式跑一段时间后再按白名单用户、百分比流量、分区域这样的顺序逐步灰度。灰度期间必须做好两个能力一键降级到人工流程、完整回看每个Agent任务的过程。即使出了大问题也能在几分钟内止血不会造成不可逆影响。线上反馈则是最被低估的宝藏。我在Agent交互里常驻了三个按钮结果满意、结果需修改、完全不对。用户点需修改时我会让他顺带写一句期望这个数据回流到样本池中比任何人工标注都更接近真实需求。第一批种子数据在上线两周后就积累了上百条高质量修正样本后来模型Prompt的迭代方向基本都是这些反馈推着走的。评测和反馈闭环才是伙伴持续进化的燃料。7. 系列小结我在落地Agent过程中真正信了和不信的事如果要在这一篇的结尾留一点最有价值的东西我想把这段时间沉淀下来的信念和偏见都摊开说。7.1 我信的三件事第一把LLM当控制器而不是执行器。凡是确定性计算比如精确统计、规则过滤、固定格式转换就不该让模型干。用代码和传统算法完成LLM只负责理解目标、拆解任务、选择路径、汇总结果。这套分工让系统稳定性高出很多。第二状态与记忆是Agent的骨架。没有状态Agent只是一个接一个孤立问答没有记忆Agent永远把用户当陌生人。长任务的每一步持久化、记忆摘要的及时沉淀是所有智能感的地基。第三人类介入是特性不是缺陷。很多团队羞于承认自己的Agent还需要人工确认总想做一个完全自主的东西。事实证明用户并不反感合理的确认环节他们反感的是不可预测的黑盒。把用户放进循环里Agent看起来反而更聪明。7.2 我不信的三件事第一我不信一个全能Agent解决所有问题的叙事。任务越通用模型决策空间越大出错率越高。我更喜欢为每个场景配置窄而深的Agent配合动态工具集把一个领域做透。第二我不信多Agent一定比单Agent强。多Agent在演示视频里很热闹但真实系统的通信开销、决策冲突和成本翻倍都非常现实。没有一个强有力的编排协议和容错设计三四个Agent同时跑就是在制造混乱。第三我不信工具越多Agent越强。工具数量超过模型的有效选择范围后误用率会明显上升。精品工具集、好描述、动态装配远比一个庞大笨重的工具箱有效。7.3 给后来者的学习路线提示很多朋友问Agent开发的学习路线我的建议永远是倒着学先实现一个单Agent的完整闭环包括工具调用和错误恢复再给它加持久化状态和长期记忆然后搭评测和灰度体系最后才碰多Agent协作。上来就学各种花哨框架反而容易迷失。论文要读但读到能回答这个机制解决什么问题、成本是多少、在什么条件下失效就够了。工业界真正的分水岭从来不是谁读过更多新论文而是谁能在真实流量里让Agent稳定地、可控地、可解释地完成任务。如果让我给这一篇加个副标题我想写的是别再用工具思维做Agent了否则你只会得到一个更贵的接口封装。后续几篇我会把工具调用、记忆方案、并发架构、安全审计这些硬骨头一个个拆开讲每一篇都会带上具体的配置、数据和踩坑过程。
阅读完成 · 觉得有帮助？
