最近又有人在群里问你的 agent 到底是真能干活还是套了个壳的 API 调用流水线这个问题问得很尖锐因为圈子里对 agent 的理解正在快速分化。我做了两年多大模型应用开发从最早的给 LLM 接个工具函数到现在的让一个具备记忆和目标感的智能体自主完成端到端任务最大的感受是当我们需要 agent 完成的从回答变成完成时整个技术栈的构建方式都会变。标题里说的从工具到伙伴不是营销话术而是我在论文和工业界项目里反复验证过的一条真实分界线。这篇文章是这个总结系列的第一篇我会聚焦范式跃迁这个核心命题把 agent 架构究竟发生了什么变化、工业界落地时哪些环节最容易被忽视、以及我踩过的坑一并讲清楚。内容会比较长适合正在做大模型应用、准备把 agent 推向生产环境的朋友也适合还在纠结agent 和 workflow 到底有什么不同的初学者。1. 我理解的范式跃迁从高级工具脚本到有目标的协作实体说到 agent 范式跃迁很多人会直接想到工具调用这个能力。但说实话工具调用本身并不新鲜2023 年的很多项目就已经在做识别意图、调用 API、返回结果这条链路了。我当时在做的第一个客服 agent 就是这个套路用户说我要查流量模型识别出意图系统调一下流量接口把结果拼成一句话返回。这种形态今天依然大量存在但我不认为它是伙伴它更像一个会说话的开关。1.1 工具时代的 agent本质上是在做条件分支工具时代的 agent核心特征是确定性优先。开发者会把所有可能的路径画成流程图意图 A 走分支 A意图 B 走分支 B模型只是负责路由的那块智能组件。这种设计的优点是可控、可测、成本低出了任何问题都能立刻定位到某个分支里去。缺点也很明显它只能处理预见到的情况。举一个我实际遇到过的例子。某个订单管理 agent预设流程是查询订单状态 → 判断是否可退款 → 调用退款接口 → 返回结果。这套流程在 80% 的场景下没有问题但一旦遇到订单状态异常需要用户先补充材料才能退款这种不在预设分支里的情况agent 就直接卡死了。用户问为什么退不了整个链路没有兜底逻辑最后只能转人工。这个案例特别典型地反映了一个问题预设流程本质上是把任务的复杂度转移给了开发者。每新增一种异常情况开发者就要在流程图上画一个新的分支。当业务足够复杂的时候分支会多到开发者自己都无法维护这就是为什么很多 agent 项目在原型阶段很惊艳一到真实业务就废掉的核心原因——你不是在开发智能体你是在开发一个永远写不完的 if-else。1.2 伙伴时代的 agent以目标为锚点以环境反馈为驱动范式跃迁发生在我开始接受一种新的设计理念之后不要让模型按预设路径走而是给模型一个目标让它在环境中自己找路。同样还是订单处理这个场景伙伴式 agent 接收的目标是帮用户完成退款但它不需要被限定在固定三步里。它会在执行过程中自查订单状态是否允许退款如果异常它自己决定是去调另一个查询接口查原因还是向用户提问获取更多信息甚至临时调整工具调用的顺序来绕过阻塞。支撑这种自主行为的底层机制是论文里反复提到的几个循环结构。最简单的 ReAct 模式是思考-行动-观察循环模型每一轮先想根据当前情况我该做什么然后调用工具再根据工具返回的观察结果进入下一轮思考。更进阶的 Reflexion 会在循环里加入自我反思失败之后不仅能重试还能总结我刚才为什么失败、下次该怎么避免。Plan-and-Solve 则把过程拆成先制定计划、再逐步执行、执行中根据反馈修订计划。这些论文思想落到工程上对应的是三种能力的补齐目标保持能力模型在长链路执行中不会忘记最初要帮用户达成什么每一步行动都服务于这个大目标。路径规划与修订能力遇到阻塞时不会直接终止而是能基于环境反馈调整策略。自主澄清能力信息不足时主动向用户提问而不是猜一个默认值继续做。1.3 范式跃迁为什么恰好发生在现在任何一个范式跃迁背后都有客观条件的成熟。agent 从工具走向伙伴我认为恰好踩中了三个技术红利。首先是模型的推理能力出现了质的提升。2023 年的模型做多步推理很容易崩三步以上的计划-执行-反思循环基本不可用现在的模型在复杂工具调度、长上下文理解、错误自我修正上的表现已经达到了可以支撑自主循环的最低门槛。吴恩达的 agent 教程里反复强调一个观点agent 技术栈的价值不在于单个模型的智商而在于如何把推理、工具、记忆、行动组合成循环这本质上是在设计体外的认知脚手架。其次是上下文窗口的持续扩张。工具时代我们给模型塞的上下文非常有限所以要靠流程拆解来降低单次决策的复杂度。现在大上下文窗口让 agent 可以在一次思考中携带足够多的工具描述、业务规则和历史记忆这让让模型自己判断该用什么工具变成了一个现实选项而不是奢侈品。最后是工具生态和协议层面的标准化。MCP 这类协议出现后工具不再是一个个散装的 API而是一套可以被 agent 动态发现、按需加载的资源体系。这种工具即插即用的标准化正好是伙伴式 agent 需要的土壤——它不再是开发者手动挂载的脚本集合而是 agent 可以自主检索和组合的外部能力空间。从我的实践经验看三者缺一不可。如果模型推理能力不够自主循环就是灾难现场如果上下文窗口太小工具选择就做不出深度如果工具没有标准化agent 每一次接入新能力都要重新开发。从工具到伙伴的跃迁本质上是这三条曲线交汇的必然结果。2. 把 agent 拆开看Harness 与模型本体的分层设计harness 和 agent 区别这个话题频繁出现在热搜里说明很多人仍然把 agent 简单地理解为一个会调用工具的模型。这是工业界一个非常大的误区。我在做线上 agent 系统时最核心的架构决策就是把 agent 拆成两层模型本体LLM Core和智能体外壳Agent Harness。模型本体负责思考外壳负责感知、行动、记忆、安全这些围绕思考展开的机制。2.1 为什么必须把两层拆开先说结论不拆分的 agent 项目很快就会遇到三个难以逾越的问题。第一是换模型成本极其高昂。如果你的业务规则、工具调度逻辑、上下文组装方式全部揉在系统提示词里那么模型从 GPT 换成某个开源模型或者从 V3 升到 V4整个 prompt 都要重新设计调试。而分层的架构下模型本体只是一个可替换的推理引擎外层机制完全不依赖具体模型的特殊性。我建立过一套 agent 服务底座模型在两周内从闭源切换到开源模型中间只改了一个配置项——因为所有的工具注册、记忆读取、结果校验都由 harness 层负责模型只需要遵守统一的输入输出协议。第二是能力扩展缺乏边界。不分层的时候每新增一种工具、一种记忆类型你都要去改主 promptprompt 会越来越长最终长到模型根本读不进去。分层之后工具注册表、记忆系统、安全过滤器都是独立的模块新增工具只需要在注册表里加一条描述新增记忆类型只需要扩展记忆接口主 prompt 几乎不动。第三是调试和观测没有抓手。伙伴式 agent 的决策链路很复杂如果所有逻辑都在模型的黑盒里出了问题你只能去看对话记录效率极低。有了 harness 层的显式处理每个环节都有一个独立的日志点上下文如何组装的、工具为什么被选中、结果是否通过校验——这些都可以作为结构化数据输出这也是后面讲可观测性的基础。2.2 Harness 层的最小可落地结构一个能支撑伙伴式 agent 的 harness 层我的实践里至少包含五个组件。下面给出一个我常用的最小化结构注意这里不是完整代码而是运行时核心循环的骨架class AgentRuntime: def __init__(self): self.tool_registry ToolRegistry() # 工具注册表 self.memory MemorySystem() # 记忆系统 self.policy SafetyPolicy() # 安全与权限策略 self.observer Observer() # 运行观测与审计 async def run(self, user_goal: str): # 初始化执行状态保存目标、计划、轨迹 state ExecutionState(goaluser_goal) for step in range(self.max_steps): # 1. 组装上下文把目标、历史轨迹、相关记忆、工具列表给模型 context self.build_context(state) # 2. 调用模型解析出下一个动作决策 action await self.llm.act(context) # 3. 如果动作是任务完成进入结果校验 if action.is_finish(): return self.policy.verify_and_package(state) # 4. 如果动作是调用工具先过安全策略再执行 if action.is_tool_call(): allowed self.policy.check_tool(action.tool_name, action.args) if not allowed: state.append_blocked_action(action) continue result await self.tool_registry.execute(action) # 5. 把结果写入轨迹和短期记忆 state.update_trace(action, result) # 6. 每一步都交给观测器记录关键决策信息 self.observer.record(step, action, result) # 到达最大步数仍未完成按退化策略处理 return self.policy.handle_timeout(state)这个骨架看起来简单但它强制建立了一个非常重要的习惯agent 的每一步都必须经过上下文组装 → 模型决策 → 安全校验 → 工具执行 → 轨迹记录这个标准闭环。前期图省事跳过任何一步后期都会付出更大的代价。2.3 上下文组装与 Token 预算控制Harness 层里最容易被忽视的细节是上下文组装。伙伴式 agent 要面对的工具可能有几十个再加上历史记忆、对话轨迹如果全量塞进提示词再大的上下文窗口也不够用。我在一个真实项目里统计过挂载 30 个工具每个工具描述平均 300 token光工具描述就占 9000 token再加上系统提示、对话历史、业务规则单轮请求直接逼近 2 万 token。这还只是单轮agent 跑一个 10 步任务总消耗量非常惊人。为了解决这个问题我在 harness 层引入了工具预检索机制不再把全部工具描述发给模型而是根据当前执行目标和已有轨迹从工具注册表里检索最相关的前 5-8 个工具只把这些工具的完整描述放进上下文。检索可以用 embedding 相似度也可以结合关键词和标签的混合策略。实测下来单轮 token 消耗下降了一多半工具选择的准确率几乎没有下降因为一个任务在任意时刻真正可能用到的工具数量通常远小于注册表总量。同样的策略也适用于记忆读取。上下文组装时只读取与当前目标强相关的记忆片段而不是把用户三个月的对话历史全部塞进去。这种按需检索 分层摘要的做法是上下文工程的核心方法论也是从工具走向伙伴过程中 token 成本控制的关键。3. 让 agent 拥有记性工业级记忆机制的三层结构与落地细节如果说 harness 层的分层设计是骨架那记忆系统就是血肉。工具时代的 agent 不需要记忆因为它每次调用都是独立的一次性交易但伙伴式 agent 的核心特征之一就是**记得住你是谁、记得住上次聊到哪、记得住哪些方案被否决过**。我在agent 记忆和agent 存储 working memory这两个话题上投入了大量时间下面分享一套经过生产验证的三层记忆架构。3.1 Working Memory执行过程中的临时工作台Working Memory工作记忆是 agent 在当前任务执行期间保存的临时状态包括当前目标、计划、已执行的步骤、每一步的工具输入输出、还未解决的阻塞问题。它的生命周期通常只覆盖一次任务任务结束就可以归档。在工程实现上Working Memory 不一定要放到外部存储里可以直接放在运行时对象中也可以放在 Redis 这类短缓存里关键是要支持快速读写和索引因为每一步循环都要频繁访问。这里有一个非常容易踩的坑很多人把全部对话历史当成 working memory 塞给模型导致上下文越来越长模型反而抓不住重点。我的做法是把 working memory 拆成两层一层是精简的当前状态摘要包括目标、当前计划、最近几步的关键结果始终保持在几百 token 内另一层是完整轨迹日志用于排查和回溯不直接进上下文。3.2 长期记忆Episodic 与 Semantic 的分工长期记忆我习惯再拆成两类Episodic Memory情景记忆和 Semantic Memory语义记忆。Episodic Memory 记录的是发生过的事情比如某次任务中用户抱怨过上次退款太慢了、某个接口在特定场景下容易超时。它保存的是场景-动作-结果的完整故事。Semantic Memory 保存的则是提取出来的知识比如用户的偏好、业务领域的规则、工具使用的最佳实践。它更像一个知识库不断从 episodic 记忆里提炼和沉淀。为什么必须拆成两层因为它们的更新频率和检索方式不一样。Episodic 是高频写入、低度提炼的主要用于回答之前发生了什么Semantic 是低频写入、高度提炼的主要用于指导接下来应该怎么做。如果混在一个表里检索结果往往会很杂相关性排序很难做好。下面是我常用的三层记忆结构参考记忆层级存储内容推荐存储方式更新策略使用场景Working Memory当前目标、计划、轨迹、临时结果运行时对象 / Redis每步覆写当前任务内的决策支持Episodic Memory历史任务的关键场景与结果数据库 / 文档存储任务结束后追加经验借鉴与复盘Semantic Memory用户偏好、业务规则、领域知识向量库 摘要索引定期提炼、冲突消解长期、跨任务的决策依据3.3 记忆落地时的三个高频问题三层结构听起来很顺实际落地时我反复遇到三个问题这里展开说一下。第一个是写入时机。不是所有对话内容都值得记。我在早期把每一轮对话都写入长期记忆结果向量库很快变得又杂又乱检索出来的东西大量无关。后来改为事后提炼 触发式写入只有任务完成、用户明确表达了偏好、或者出现了执行异常时才触发记忆写入写入前先做一个摘要和结构化提取。这样长期记忆的增长速度会慢很多但每条都值得参考。第二个是检索与重排。长期记忆用向量库检索出 top-k 之后不能直接塞给模型。我通常还会做一个重排rerank结合三个信号与当前目标的相关性、记忆产生的时间越新越重要、以及记忆来源的可信度人工确认过的 模型推断的。重排之后只取前 3-5 条高质量记忆进上下文效果远好于盲目取 top-k。第三个是冲突消解。用户今天说我以后都用文档 A 的格式但三天前还要求在任务里使用模板 B。如果记忆系统把两条都返回给模型模型会非常困惑。我的做法是给每条语义记忆加一个时间戳 置信度 状态字段冲突时根据时效性和置信度做裁决同时把旧记忆标记为已过期但保留存档避免直接删掉导致历史无法回溯。3.4 一个真实场景记忆带来的业务提升与副作用我负责过的一个企业知识助手最初也是白纸式设计每次对话都从零开始。后来接入了语义记忆记住用户所在的部门、关注的领域、偏好的回答粒度推荐内容和条款的准确率提升非常明显用户明显感觉这个助手知道我要什么。但记忆也带来了副作用。有一次系统错误地把一个用户的临时偏好当作长期偏好写入了语义记忆之后连续几次任务都出现了偏差。排查了很久才发现是记忆提取阶段的模型把用户随口一说当成了稳定偏好。那次之后我在记忆写入链路里加入了一条强制规则只有用户明确重复过、或者用户行为模式被多次验证过的信息才允许进入长期语义记忆。这个教训让我意识到记忆系统设计的一个核心原则是宁可少记不可错记——错误的记忆对伙伴式 agent 的伤害远大于没有记忆。4. 单 agent 的极限与多 agent 编排的工程代价多 agent是最近两年最热的方向之一很多团队一上来就想做多个 agent 协作。但我在实践中越来越清楚一个道理多 agent 是手段不是目的。在引入多 agent 之前必须先搞清楚单 agent 的天花板在哪里以及多 agent 编排会让系统付出什么代价。4.1 单 agent 在什么场景下会撞到天花板单 agent 的优势是简单、状态集中、调试直观。但它有一个非常现实的瓶颈决策质量会随任务步数的增加而衰减。我做过一个材料生成 agent任务链路接近 15 步中间要查多个资料库、调用多个写作模板、执行多轮格式校验。前 8 步表现还行到后面模型经常出现忘记最初目标、把中间结果搞混、对工具返回的错误信息不加验证直接继续这类问题。上下文越来越长关键信息被稀释模型开始抓不住重点。这不是模型不够聪明而是单一上下文空间的承载能力有限。解决思路有两个方向一是把长任务拆短让每一步的决策都在一个小而聚焦的上下文里完成二是引入多个 agent让不同的 agent 负责不同的子目标。这两个方向分别是流程拆分和多代理分工它们的本质都是降低单一决策点的复杂度。4.2 多 agent 的四种主流编排模式根据我的项目经验和论文阅读多 agent 的编排模式大致可以归为四类。第一种是路由调度模式。一个主管 agent 接收用户目标分析后把任务分派给不同的专家 agent各专家做完后再由主管汇总。这种模式特别适合需要多种专业能力的场景比如一份报告需要数据分析 agent、图表生成 agent、文案润色 agent 共同完成。第二种是流水线模式。任务按固定顺序经过多个 agent每个 agent 只负责处理上一个环节输出的结果。以内容生产为例选题 agent 产出大纲 → 撰写 agent 生成初稿 → 审核 agent 检查合规和事实错误 → 发布 agent 完成排版推送。流水线的优点是每个 agent 的职责边界清晰测试和维护都很容易缺点是只要一个环节失败整条线就停摆所以每个节点的输入输出校验特别重要。第三种是辩论/审校模式。两个或多个 agent 对同一件事持有不同立场互相审查、提出问题用于质量敏感的场景。比如一个 agent 生成答案另一个 agent 专门挑错挑出的问题再交回第一个 agent 修改。这种模式在论文里被验证能提升推理和事实准确性但成本很高运行速度也慢不适合高频场景。第四种是显式图编排模式。用有向图状态机的形式定义整个任务流程节点是 agent 或工具边是状态转移条件。LangGraph 就是这类实现的代表。它对什么时候该走哪条路有极强的控制力适合流程复杂但又需要高确定性的业务比如金融审批、医疗分诊。4.3 多 agent 协作最容易被低估的三个代价多 agent 不是银弹我在项目里吃过不少苦头下面三个代价建议每一位准备做多 agent 的开发者提前了解。第一是错误放大效应。下游 agent 收到上游 agent 的错误信息时通常不会察觉错误而是会在这个错误基础上一本正经地继续往下做。所以多 agent 系统里每个 agent 之间的输入输出都必须设计结构化校验——不能只是把文本丢给下一个节点至少要验证格式、校验关键字段、标记置信度。我们的做法是在所有生产级的 agent 间引入一个共享状态层任何 agent 的输出都会先经过一个校验器再写入共享状态供下游读取。第二是上下文隔离与传递的成本。多个 agent 各自拥有自己的上下文彼此之间怎么传信息如果只靠文本拼接传递很容易丢失信息。我们的方案是传递结构化任务包包含目标、已知约束、输入数据引用、输出规范、置信度标注。这种传递方式比把上一轮的对话记录直接拼进下一轮更可靠也更省 token。第三是可观测性的复杂度指数级上升。单个 agent 的决策已经很难跟踪了多个 agent 协同时的链路长度和分支数量会成倍增长。如果一个多 agent 任务最终结果错了你要定位是哪一个 agent 的哪个环节出了问题如果没有每一层完整的输入输出日志排查会非常痛苦。所以做多 agent 之前务必先把日志体系打好每个 agent 的输入摘要、输出摘要、耗时、token 消耗都必须落库。4.4 与ai agent 怎么扛并发相关的架构思考热搜里还有一个高频问题ai agent 怎么扛并发。很多人觉得 agent 并发就是多线程调用大模型 API这种理解把问题想简单了。agent 的每个任务都是由多步循环组成的每一步之间还有状态依赖如果并发执行时不做好状态隔离两个任务很容易串数据。我见过的线上事故里A 用户的上下文串到了 B 用户的请求里绝对排得上前三名。我的实践经验是线上 agent 服务的并发架构核心不是多线程调用模型而是四大关键设计——状态隔离、幂等设计、速率限制、优雅降级。状态隔离每个任务实例的 working memory、上下文快照、执行轨迹都必须按任务 ID 隔离存储不允许任何共享可变状态。用 Redis 按 task_id 做 key 空间隔离是最简单的方案。幂等设计agent 调用外部工具时可能因为超时会重试如果工具不是幂等的比如创建订单发送通知重试就会产生重复数据。必须在 harness 层给每个工具调用生成唯一的 request_id工具侧做去重。速率限制模型 API 有速率上限工具接口也有各自的 QPS 限制。agent 系统需要一个全局限流器按目标维度和优先级做配额管理而不是让每个任务无节制地竞争资源。优雅降级高峰期实在扛不住时不能直接拒绝用户而是降级为排队 通知模式或者把复杂任务降级为简化流程。这一点在设计时就要考虑清楚。这些内容展开写能写一整篇这里先点到为止后续系列我会专门聊 agent 生产环境的架构治理。5. 可靠性与并发从跑得通到扛得住很多 agent 项目在 demo 阶段非常顺利线上跑了不到一周就暴露出大量问题。最典型的就是热搜里反复出现的报错agent execution terminated due to error.这个错误几乎是每个 agent 开发者的 人生第一课。我在生产环境见过太多次这条报错它背后不是一个问题而是一类问题。5.1 把 terminated due to error 拆开来看我对线上积累的错误样本做过归类发现高频原因集中在四类错误类型具体表现出现频率模型输出格式不合法模型明明接收到输出 JSON的指令却返回了普通文本或者 JSON 截断无法解析很高工具调用异常工具接口超时、返回数据格式与预期不符、权限校验失败很高上下文超限长任务执行中累积历史轨迹加上工具返回的大段数据单轮请求超过模型上下文上限中等外部依赖故障上游 API 限流、数据库连接异常、第三方服务不可用中等看到这些错误很多人的第一反应是优化模型调用。但我的经验是大多数 termination 错误不是模型的问题而是 harness 层缺少错误恢复机制。模型本身是有能力从错误中恢复的关键在于你有没有给它恢复的机会和机制。5.2 让 agent 学会自救从 fail-fast 到 fail-retry 的改造我早期设计的 agent 循环很脆只要某一步工具调用抛异常整个任务直接终止把错误抛给用户。现在回头看这是最典型的工具式思维——把 agent 当成了普通程序程序抛异常就应该终止。但伙伴式 agent 应该具备遇到问题不慌张、自己找路走的能力。改造的核心是给模型的每一步决策提供结构化错误信息并允许它重新决策。下面是我常用的黄金规则工具调用失败时不要只返回error要返回结构化的错误详情失败原因、错误类型超时/校验失败/权限不足、可能的补救建议、是否值得重试。模型看到错误后应该被允许选择三条路之一换一组参数重试、改用其他工具、向用户澄清。只有当三条路都不可行或者重试次数超限才允许任务终止。每次重试都要有退避策略。工具超时后立刻重试往往还是超时间隔几秒甚至指数退避再试成功的概率要高得多。设定最大重试次数我通常设 2-3 次超出后进入人工兜底或降级处理分支而不是无限循环烧 token。这里的关键不是机械地加重试而是让错误信息成为模型下一步决策的输入。模型是具备推理能力的它拿到接口超时服务端可能过载和接口返回 403疑似权限失效这两种错误时会采取完全不同的后续行动。如果你只是把异常堆栈丢给它它也只能懵。5.3 可观测性没有轨迹审计就没有 agent 运维把 agent 当作伙伴之后还有一个必须补上的能力就是可观测性。你不可能用一个黑盒去服务用户。我在生产环境里要求每个 agent 任务都必须产出完整的决策轨迹记录包括每一步的输入上下文摘要、模型决策结果、选中的工具与参数、工具返回摘要、校验结果、耗时和 token 消耗。这套轨迹有三层价值。第一层是线上问题定位——用户投诉时可以直接回放整个决策轨迹找出是哪一步决策出了问题。第二层是数据飞轮——积累大量成功轨迹和失败轨迹之后可以用来做评测集、微调数据、prompt 优化依据。第三层是安全审计——确保 agent 没有在用户不知情的情况下执行敏感操作。轨迹记录的成本也不低每一步都存完整对话记录会非常占空间。我的做法是分层存储完整轨迹存冷存储对象存储或归档库按任务 ID 可检索近期的精简轨迹只存关键动作摘要存热存储方便快速查看。5.4 安全护栏工具权限最小化与敏感操作管控说到agent 安全很多人想到的是防止模型输出违规内容但工业界更紧迫的是工具权限的失控风险。当 agent 具备自主调用工具的能力后它可能在用户没有明确确认的情况下调用了删除付款发送这类高危操作。我在一个项目里就出现过一次agent 为了完成整理订阅列表的任务居然触发了退订接口——好在接口本身有权限校验拦住了。我的安全实践包含四条铁律工具权限最小化每个 agent 只挂载完成业务目标所必需的工具高危工具默认不开放确需开放时必须走人工审核流程。敏感操作二次确认执行删除、支付、发送消息、修改关键数据这类操作前agent 必须先生成操作确认请求发给用户用户点击确认后才继续。输出内容护栏模型生成用于展示给用户的内容必须过内容安全过滤器防止诱导违规、恶意代码、隐私泄露等风险。全链路审计所有工具调用无论成功失败都必须记录到审计日志包含调用者任务 ID、目标、参数、结果、时间戳。这是安全追溯的基础。这一节讲的内容偏工程治理但这些都是从工具到伙伴绕不开的功课——伙伴意味着更大的自主权更大的自主权意味着更强的约束和更完善的监督机制。想清楚这一点agent 项目在工业界才真正站得住脚。6. 评测、安全与框架选型2026 年做 agent 绕不开的三个现实问题最后聊一聊做 agent 的顶层设计问题评测体系怎么搭、框架怎么选、现在的生态应该怎么看。这些话题在网上讨论很多但大多是泛泛而谈我说说我的实操经验。6.1 评测没有评测集的 agent 项目等于裸奔Agent 评测比传统 NLP 评测难得多因为它没有一个标准答案。传统模型评测可以算 rouge、bleu、准确率但 agent 的核心指标是在真实环境里能不能把事办成。我的做法是维护一套分层评测体系。第一层是确定性评测。准备一批标准任务集每个任务有明确的目标和预期结果跑完之后检查是否达成。例如给用户 X 查询本月账单并生成摘要预期结果是账单数据准确、摘要包含关键项。这一层保证的是 agent 的基本完成能力。第二层是过程质量评测。任务完成了但完成得是否规范我关注四个指标步骤成功率每一步工具调用是否成功、平均步数完成任务是否绕路、token 成本单位任务消耗、延迟端到端耗时。这四个指标直接决定生产可用性。一个任务跑了 20 步才完成哪怕结果是对的线上也扛不住成本和延迟。第三层是对抗与边角评测。故意构造异常场景接口超时、用户输入模糊、工具返回脏数据、多步任务中途状态丢失。这一层测的是 agent 的韧性和兜底能力。评测集建立之后要持续积累线上失败案例定期补充进任务集。参考 AgentBench、GAIA 这类公开 benchmark 的思路是好的但一定要基于自己的业务造题——公开 benchmark 验证的是 agent 的通用能力你自己的评测集验证的是它在你业务里能不能活下来。这两个都必须有。6.2 框架选型按团队和场景选别按热度选主流的 agent 框架有哪些这个问题我几乎每周都会被问。说实话框架之间的差异远没有宣传里说的那么大更重要的是框架的编排范式是否匹配你的业务。下面是我对这些框架的实际使用感受框架编排范式适合场景主要注意点LangGraph显式图/状态机流程复杂、需要精细控制学习曲线较陡概念多但工程化能力最强AutoGen / AG2对话式多 agent多 agent 协作研究型项目动态对话逻辑较灵活但可控性较差CrewAI角色化多 agent快速原型、轻量业务上手快复杂状态管理偏弱Semantic Kernel插件化框架微软生态、企业集成和 Azure 生态绑定较深Spring AI注解式集成Java 技术栈、传统企业对 Java 团队友好生态相对年轻扣子 / Dify低代码平台非技术同学快速搭助手适合 MVP深度定制受限Google ADK模型驱动编排JVM 系、Kotlin/Java 场景新的框架资料较少我的选型建议很简单如果你的团队主要是 Python 工程师、业务流程偏复杂、需要断点恢复和人工审批节点LangGraph 是当前最稳的选择。如果团队是 Java 栈、要快速集成到现有 Spring 体系里Spring AI 值得认真看不必因为它不够热就跳过。如果是产品经理想自己搭个 demo 验证想法扣子这类低代码平台完全可以先跑起来但别指望它支撑复杂的生产逻辑。还有一个经常被忽略的判断标准是否需要长时运行与断点恢复。伙伴式 agent 的任务可能持续很久中间可能中断、需要恢复、需要人工介入。这种场景下框架对 持久化状态 的支持能力是第一优先级。我目前的经验是LangGraph 的 checkpointer 机制和显式状态管理是几个框架里最成熟的。6.3 2026 年国内的 agent 生态观察与中台化趋势从这两年的行业观察来看国内 agent 产品正在走向中台化。很多团队不再从零造一个 agent而是基于公司内部的 agent 中台做配置。这种模式对业务的帮助很大工具注册、权限管理、可观测性、评估体系都在中台里统一建设业务方只需要关注提示词和流程编排。但中台化也带来一个新的问题过度标准化可能会限制 agent 的深度发挥。一些业务团队拿到中台后习惯性地把 agent 用回了流程图自动化的老路子——这其实是在开倒车。我始终认为无论你用中台还是自研核心的认知不能丢agent 的价值在于目标驱动 自主决策 记忆积累 自我修正这套范式的组合而不在于你用了哪个框架、挂了哪些标签。扣子这类平台的兴起让搭 agent变成了一个低门槛操作这是好事因为更多人可以快速验证想法。但真正进入生产环境的时候你会发现决定成败的还是那些反直觉的深水区记忆的污染与消解、工具的权限与安全、错误的恢复与重试、评测集的持续积累。这些没有捷径只能一个个踩过来。最后再分享一点我的个人体会。做 agent 这一年多我最深的感受是不要把一个 agent 当作一个功能去实现而是要把它当作一个同事去管理。功能是确定性的输入输出可预测同事是目标导向的你给它清晰的目标、可用的工具、充分的背景、安全的边界它会在不确定的环境里自己想办法。从工具到伙伴的跃迁说到底就是你能不能接受这种可控的失控——在充分的约束和安全机制内允许模型自主地走出一条你没预想过的路径。接受这一点之后你的 agent 项目才算真正越过了那道分界线。这个系列下一篇我打算聊 agent 的评测体系与数据飞轮把这次只点到为止的部分展开。 从工具到伙伴：AI Agent范式跃迁与生产级架构实践
最近又有人在群里问你的 agent 到底是真能干活还是套了个壳的 API 调用流水线这个问题问得很尖锐因为圈子里对 agent 的理解正在快速分化。我做了两年多大模型应用开发从最早的给 LLM 接个工具函数到现在的让一个具备记忆和目标感的智能体自主完成端到端任务最大的感受是当我们需要 agent 完成的从回答变成完成时整个技术栈的构建方式都会变。标题里说的从工具到伙伴不是营销话术而是我在论文和工业界项目里反复验证过的一条真实分界线。这篇文章是这个总结系列的第一篇我会聚焦范式跃迁这个核心命题把 agent 架构究竟发生了什么变化、工业界落地时哪些环节最容易被忽视、以及我踩过的坑一并讲清楚。内容会比较长适合正在做大模型应用、准备把 agent 推向生产环境的朋友也适合还在纠结agent 和 workflow 到底有什么不同的初学者。1. 我理解的范式跃迁从高级工具脚本到有目标的协作实体说到 agent 范式跃迁很多人会直接想到工具调用这个能力。但说实话工具调用本身并不新鲜2023 年的很多项目就已经在做识别意图、调用 API、返回结果这条链路了。我当时在做的第一个客服 agent 就是这个套路用户说我要查流量模型识别出意图系统调一下流量接口把结果拼成一句话返回。这种形态今天依然大量存在但我不认为它是伙伴它更像一个会说话的开关。1.1 工具时代的 agent本质上是在做条件分支工具时代的 agent核心特征是确定性优先。开发者会把所有可能的路径画成流程图意图 A 走分支 A意图 B 走分支 B模型只是负责路由的那块智能组件。这种设计的优点是可控、可测、成本低出了任何问题都能立刻定位到某个分支里去。缺点也很明显它只能处理预见到的情况。举一个我实际遇到过的例子。某个订单管理 agent预设流程是查询订单状态 → 判断是否可退款 → 调用退款接口 → 返回结果。这套流程在 80% 的场景下没有问题但一旦遇到订单状态异常需要用户先补充材料才能退款这种不在预设分支里的情况agent 就直接卡死了。用户问为什么退不了整个链路没有兜底逻辑最后只能转人工。这个案例特别典型地反映了一个问题预设流程本质上是把任务的复杂度转移给了开发者。每新增一种异常情况开发者就要在流程图上画一个新的分支。当业务足够复杂的时候分支会多到开发者自己都无法维护这就是为什么很多 agent 项目在原型阶段很惊艳一到真实业务就废掉的核心原因——你不是在开发智能体你是在开发一个永远写不完的 if-else。1.2 伙伴时代的 agent以目标为锚点以环境反馈为驱动范式跃迁发生在我开始接受一种新的设计理念之后不要让模型按预设路径走而是给模型一个目标让它在环境中自己找路。同样还是订单处理这个场景伙伴式 agent 接收的目标是帮用户完成退款但它不需要被限定在固定三步里。它会在执行过程中自查订单状态是否允许退款如果异常它自己决定是去调另一个查询接口查原因还是向用户提问获取更多信息甚至临时调整工具调用的顺序来绕过阻塞。支撑这种自主行为的底层机制是论文里反复提到的几个循环结构。最简单的 ReAct 模式是思考-行动-观察循环模型每一轮先想根据当前情况我该做什么然后调用工具再根据工具返回的观察结果进入下一轮思考。更进阶的 Reflexion 会在循环里加入自我反思失败之后不仅能重试还能总结我刚才为什么失败、下次该怎么避免。Plan-and-Solve 则把过程拆成先制定计划、再逐步执行、执行中根据反馈修订计划。这些论文思想落到工程上对应的是三种能力的补齐目标保持能力模型在长链路执行中不会忘记最初要帮用户达成什么每一步行动都服务于这个大目标。路径规划与修订能力遇到阻塞时不会直接终止而是能基于环境反馈调整策略。自主澄清能力信息不足时主动向用户提问而不是猜一个默认值继续做。1.3 范式跃迁为什么恰好发生在现在任何一个范式跃迁背后都有客观条件的成熟。agent 从工具走向伙伴我认为恰好踩中了三个技术红利。首先是模型的推理能力出现了质的提升。2023 年的模型做多步推理很容易崩三步以上的计划-执行-反思循环基本不可用现在的模型在复杂工具调度、长上下文理解、错误自我修正上的表现已经达到了可以支撑自主循环的最低门槛。吴恩达的 agent 教程里反复强调一个观点agent 技术栈的价值不在于单个模型的智商而在于如何把推理、工具、记忆、行动组合成循环这本质上是在设计体外的认知脚手架。其次是上下文窗口的持续扩张。工具时代我们给模型塞的上下文非常有限所以要靠流程拆解来降低单次决策的复杂度。现在大上下文窗口让 agent 可以在一次思考中携带足够多的工具描述、业务规则和历史记忆这让让模型自己判断该用什么工具变成了一个现实选项而不是奢侈品。最后是工具生态和协议层面的标准化。MCP 这类协议出现后工具不再是一个个散装的 API而是一套可以被 agent 动态发现、按需加载的资源体系。这种工具即插即用的标准化正好是伙伴式 agent 需要的土壤——它不再是开发者手动挂载的脚本集合而是 agent 可以自主检索和组合的外部能力空间。从我的实践经验看三者缺一不可。如果模型推理能力不够自主循环就是灾难现场如果上下文窗口太小工具选择就做不出深度如果工具没有标准化agent 每一次接入新能力都要重新开发。从工具到伙伴的跃迁本质上是这三条曲线交汇的必然结果。2. 把 agent 拆开看Harness 与模型本体的分层设计harness 和 agent 区别这个话题频繁出现在热搜里说明很多人仍然把 agent 简单地理解为一个会调用工具的模型。这是工业界一个非常大的误区。我在做线上 agent 系统时最核心的架构决策就是把 agent 拆成两层模型本体LLM Core和智能体外壳Agent Harness。模型本体负责思考外壳负责感知、行动、记忆、安全这些围绕思考展开的机制。2.1 为什么必须把两层拆开先说结论不拆分的 agent 项目很快就会遇到三个难以逾越的问题。第一是换模型成本极其高昂。如果你的业务规则、工具调度逻辑、上下文组装方式全部揉在系统提示词里那么模型从 GPT 换成某个开源模型或者从 V3 升到 V4整个 prompt 都要重新设计调试。而分层的架构下模型本体只是一个可替换的推理引擎外层机制完全不依赖具体模型的特殊性。我建立过一套 agent 服务底座模型在两周内从闭源切换到开源模型中间只改了一个配置项——因为所有的工具注册、记忆读取、结果校验都由 harness 层负责模型只需要遵守统一的输入输出协议。第二是能力扩展缺乏边界。不分层的时候每新增一种工具、一种记忆类型你都要去改主 promptprompt 会越来越长最终长到模型根本读不进去。分层之后工具注册表、记忆系统、安全过滤器都是独立的模块新增工具只需要在注册表里加一条描述新增记忆类型只需要扩展记忆接口主 prompt 几乎不动。第三是调试和观测没有抓手。伙伴式 agent 的决策链路很复杂如果所有逻辑都在模型的黑盒里出了问题你只能去看对话记录效率极低。有了 harness 层的显式处理每个环节都有一个独立的日志点上下文如何组装的、工具为什么被选中、结果是否通过校验——这些都可以作为结构化数据输出这也是后面讲可观测性的基础。2.2 Harness 层的最小可落地结构一个能支撑伙伴式 agent 的 harness 层我的实践里至少包含五个组件。下面给出一个我常用的最小化结构注意这里不是完整代码而是运行时核心循环的骨架class AgentRuntime: def __init__(self): self.tool_registry ToolRegistry() # 工具注册表 self.memory MemorySystem() # 记忆系统 self.policy SafetyPolicy() # 安全与权限策略 self.observer Observer() # 运行观测与审计 async def run(self, user_goal: str): # 初始化执行状态保存目标、计划、轨迹 state ExecutionState(goaluser_goal) for step in range(self.max_steps): # 1. 组装上下文把目标、历史轨迹、相关记忆、工具列表给模型 context self.build_context(state) # 2. 调用模型解析出下一个动作决策 action await self.llm.act(context) # 3. 如果动作是任务完成进入结果校验 if action.is_finish(): return self.policy.verify_and_package(state) # 4. 如果动作是调用工具先过安全策略再执行 if action.is_tool_call(): allowed self.policy.check_tool(action.tool_name, action.args) if not allowed: state.append_blocked_action(action) continue result await self.tool_registry.execute(action) # 5. 把结果写入轨迹和短期记忆 state.update_trace(action, result) # 6. 每一步都交给观测器记录关键决策信息 self.observer.record(step, action, result) # 到达最大步数仍未完成按退化策略处理 return self.policy.handle_timeout(state)这个骨架看起来简单但它强制建立了一个非常重要的习惯agent 的每一步都必须经过上下文组装 → 模型决策 → 安全校验 → 工具执行 → 轨迹记录这个标准闭环。前期图省事跳过任何一步后期都会付出更大的代价。2.3 上下文组装与 Token 预算控制Harness 层里最容易被忽视的细节是上下文组装。伙伴式 agent 要面对的工具可能有几十个再加上历史记忆、对话轨迹如果全量塞进提示词再大的上下文窗口也不够用。我在一个真实项目里统计过挂载 30 个工具每个工具描述平均 300 token光工具描述就占 9000 token再加上系统提示、对话历史、业务规则单轮请求直接逼近 2 万 token。这还只是单轮agent 跑一个 10 步任务总消耗量非常惊人。为了解决这个问题我在 harness 层引入了工具预检索机制不再把全部工具描述发给模型而是根据当前执行目标和已有轨迹从工具注册表里检索最相关的前 5-8 个工具只把这些工具的完整描述放进上下文。检索可以用 embedding 相似度也可以结合关键词和标签的混合策略。实测下来单轮 token 消耗下降了一多半工具选择的准确率几乎没有下降因为一个任务在任意时刻真正可能用到的工具数量通常远小于注册表总量。同样的策略也适用于记忆读取。上下文组装时只读取与当前目标强相关的记忆片段而不是把用户三个月的对话历史全部塞进去。这种按需检索 分层摘要的做法是上下文工程的核心方法论也是从工具走向伙伴过程中 token 成本控制的关键。3. 让 agent 拥有记性工业级记忆机制的三层结构与落地细节如果说 harness 层的分层设计是骨架那记忆系统就是血肉。工具时代的 agent 不需要记忆因为它每次调用都是独立的一次性交易但伙伴式 agent 的核心特征之一就是**记得住你是谁、记得住上次聊到哪、记得住哪些方案被否决过**。我在agent 记忆和agent 存储 working memory这两个话题上投入了大量时间下面分享一套经过生产验证的三层记忆架构。3.1 Working Memory执行过程中的临时工作台Working Memory工作记忆是 agent 在当前任务执行期间保存的临时状态包括当前目标、计划、已执行的步骤、每一步的工具输入输出、还未解决的阻塞问题。它的生命周期通常只覆盖一次任务任务结束就可以归档。在工程实现上Working Memory 不一定要放到外部存储里可以直接放在运行时对象中也可以放在 Redis 这类短缓存里关键是要支持快速读写和索引因为每一步循环都要频繁访问。这里有一个非常容易踩的坑很多人把全部对话历史当成 working memory 塞给模型导致上下文越来越长模型反而抓不住重点。我的做法是把 working memory 拆成两层一层是精简的当前状态摘要包括目标、当前计划、最近几步的关键结果始终保持在几百 token 内另一层是完整轨迹日志用于排查和回溯不直接进上下文。3.2 长期记忆Episodic 与 Semantic 的分工长期记忆我习惯再拆成两类Episodic Memory情景记忆和 Semantic Memory语义记忆。Episodic Memory 记录的是发生过的事情比如某次任务中用户抱怨过上次退款太慢了、某个接口在特定场景下容易超时。它保存的是场景-动作-结果的完整故事。Semantic Memory 保存的则是提取出来的知识比如用户的偏好、业务领域的规则、工具使用的最佳实践。它更像一个知识库不断从 episodic 记忆里提炼和沉淀。为什么必须拆成两层因为它们的更新频率和检索方式不一样。Episodic 是高频写入、低度提炼的主要用于回答之前发生了什么Semantic 是低频写入、高度提炼的主要用于指导接下来应该怎么做。如果混在一个表里检索结果往往会很杂相关性排序很难做好。下面是我常用的三层记忆结构参考记忆层级存储内容推荐存储方式更新策略使用场景Working Memory当前目标、计划、轨迹、临时结果运行时对象 / Redis每步覆写当前任务内的决策支持Episodic Memory历史任务的关键场景与结果数据库 / 文档存储任务结束后追加经验借鉴与复盘Semantic Memory用户偏好、业务规则、领域知识向量库 摘要索引定期提炼、冲突消解长期、跨任务的决策依据3.3 记忆落地时的三个高频问题三层结构听起来很顺实际落地时我反复遇到三个问题这里展开说一下。第一个是写入时机。不是所有对话内容都值得记。我在早期把每一轮对话都写入长期记忆结果向量库很快变得又杂又乱检索出来的东西大量无关。后来改为事后提炼 触发式写入只有任务完成、用户明确表达了偏好、或者出现了执行异常时才触发记忆写入写入前先做一个摘要和结构化提取。这样长期记忆的增长速度会慢很多但每条都值得参考。第二个是检索与重排。长期记忆用向量库检索出 top-k 之后不能直接塞给模型。我通常还会做一个重排rerank结合三个信号与当前目标的相关性、记忆产生的时间越新越重要、以及记忆来源的可信度人工确认过的 模型推断的。重排之后只取前 3-5 条高质量记忆进上下文效果远好于盲目取 top-k。第三个是冲突消解。用户今天说我以后都用文档 A 的格式但三天前还要求在任务里使用模板 B。如果记忆系统把两条都返回给模型模型会非常困惑。我的做法是给每条语义记忆加一个时间戳 置信度 状态字段冲突时根据时效性和置信度做裁决同时把旧记忆标记为已过期但保留存档避免直接删掉导致历史无法回溯。3.4 一个真实场景记忆带来的业务提升与副作用我负责过的一个企业知识助手最初也是白纸式设计每次对话都从零开始。后来接入了语义记忆记住用户所在的部门、关注的领域、偏好的回答粒度推荐内容和条款的准确率提升非常明显用户明显感觉这个助手知道我要什么。但记忆也带来了副作用。有一次系统错误地把一个用户的临时偏好当作长期偏好写入了语义记忆之后连续几次任务都出现了偏差。排查了很久才发现是记忆提取阶段的模型把用户随口一说当成了稳定偏好。那次之后我在记忆写入链路里加入了一条强制规则只有用户明确重复过、或者用户行为模式被多次验证过的信息才允许进入长期语义记忆。这个教训让我意识到记忆系统设计的一个核心原则是宁可少记不可错记——错误的记忆对伙伴式 agent 的伤害远大于没有记忆。4. 单 agent 的极限与多 agent 编排的工程代价多 agent是最近两年最热的方向之一很多团队一上来就想做多个 agent 协作。但我在实践中越来越清楚一个道理多 agent 是手段不是目的。在引入多 agent 之前必须先搞清楚单 agent 的天花板在哪里以及多 agent 编排会让系统付出什么代价。4.1 单 agent 在什么场景下会撞到天花板单 agent 的优势是简单、状态集中、调试直观。但它有一个非常现实的瓶颈决策质量会随任务步数的增加而衰减。我做过一个材料生成 agent任务链路接近 15 步中间要查多个资料库、调用多个写作模板、执行多轮格式校验。前 8 步表现还行到后面模型经常出现忘记最初目标、把中间结果搞混、对工具返回的错误信息不加验证直接继续这类问题。上下文越来越长关键信息被稀释模型开始抓不住重点。这不是模型不够聪明而是单一上下文空间的承载能力有限。解决思路有两个方向一是把长任务拆短让每一步的决策都在一个小而聚焦的上下文里完成二是引入多个 agent让不同的 agent 负责不同的子目标。这两个方向分别是流程拆分和多代理分工它们的本质都是降低单一决策点的复杂度。4.2 多 agent 的四种主流编排模式根据我的项目经验和论文阅读多 agent 的编排模式大致可以归为四类。第一种是路由调度模式。一个主管 agent 接收用户目标分析后把任务分派给不同的专家 agent各专家做完后再由主管汇总。这种模式特别适合需要多种专业能力的场景比如一份报告需要数据分析 agent、图表生成 agent、文案润色 agent 共同完成。第二种是流水线模式。任务按固定顺序经过多个 agent每个 agent 只负责处理上一个环节输出的结果。以内容生产为例选题 agent 产出大纲 → 撰写 agent 生成初稿 → 审核 agent 检查合规和事实错误 → 发布 agent 完成排版推送。流水线的优点是每个 agent 的职责边界清晰测试和维护都很容易缺点是只要一个环节失败整条线就停摆所以每个节点的输入输出校验特别重要。第三种是辩论/审校模式。两个或多个 agent 对同一件事持有不同立场互相审查、提出问题用于质量敏感的场景。比如一个 agent 生成答案另一个 agent 专门挑错挑出的问题再交回第一个 agent 修改。这种模式在论文里被验证能提升推理和事实准确性但成本很高运行速度也慢不适合高频场景。第四种是显式图编排模式。用有向图状态机的形式定义整个任务流程节点是 agent 或工具边是状态转移条件。LangGraph 就是这类实现的代表。它对什么时候该走哪条路有极强的控制力适合流程复杂但又需要高确定性的业务比如金融审批、医疗分诊。4.3 多 agent 协作最容易被低估的三个代价多 agent 不是银弹我在项目里吃过不少苦头下面三个代价建议每一位准备做多 agent 的开发者提前了解。第一是错误放大效应。下游 agent 收到上游 agent 的错误信息时通常不会察觉错误而是会在这个错误基础上一本正经地继续往下做。所以多 agent 系统里每个 agent 之间的输入输出都必须设计结构化校验——不能只是把文本丢给下一个节点至少要验证格式、校验关键字段、标记置信度。我们的做法是在所有生产级的 agent 间引入一个共享状态层任何 agent 的输出都会先经过一个校验器再写入共享状态供下游读取。第二是上下文隔离与传递的成本。多个 agent 各自拥有自己的上下文彼此之间怎么传信息如果只靠文本拼接传递很容易丢失信息。我们的方案是传递结构化任务包包含目标、已知约束、输入数据引用、输出规范、置信度标注。这种传递方式比把上一轮的对话记录直接拼进下一轮更可靠也更省 token。第三是可观测性的复杂度指数级上升。单个 agent 的决策已经很难跟踪了多个 agent 协同时的链路长度和分支数量会成倍增长。如果一个多 agent 任务最终结果错了你要定位是哪一个 agent 的哪个环节出了问题如果没有每一层完整的输入输出日志排查会非常痛苦。所以做多 agent 之前务必先把日志体系打好每个 agent 的输入摘要、输出摘要、耗时、token 消耗都必须落库。4.4 与ai agent 怎么扛并发相关的架构思考热搜里还有一个高频问题ai agent 怎么扛并发。很多人觉得 agent 并发就是多线程调用大模型 API这种理解把问题想简单了。agent 的每个任务都是由多步循环组成的每一步之间还有状态依赖如果并发执行时不做好状态隔离两个任务很容易串数据。我见过的线上事故里A 用户的上下文串到了 B 用户的请求里绝对排得上前三名。我的实践经验是线上 agent 服务的并发架构核心不是多线程调用模型而是四大关键设计——状态隔离、幂等设计、速率限制、优雅降级。状态隔离每个任务实例的 working memory、上下文快照、执行轨迹都必须按任务 ID 隔离存储不允许任何共享可变状态。用 Redis 按 task_id 做 key 空间隔离是最简单的方案。幂等设计agent 调用外部工具时可能因为超时会重试如果工具不是幂等的比如创建订单发送通知重试就会产生重复数据。必须在 harness 层给每个工具调用生成唯一的 request_id工具侧做去重。速率限制模型 API 有速率上限工具接口也有各自的 QPS 限制。agent 系统需要一个全局限流器按目标维度和优先级做配额管理而不是让每个任务无节制地竞争资源。优雅降级高峰期实在扛不住时不能直接拒绝用户而是降级为排队 通知模式或者把复杂任务降级为简化流程。这一点在设计时就要考虑清楚。这些内容展开写能写一整篇这里先点到为止后续系列我会专门聊 agent 生产环境的架构治理。5. 可靠性与并发从跑得通到扛得住很多 agent 项目在 demo 阶段非常顺利线上跑了不到一周就暴露出大量问题。最典型的就是热搜里反复出现的报错agent execution terminated due to error.这个错误几乎是每个 agent 开发者的 人生第一课。我在生产环境见过太多次这条报错它背后不是一个问题而是一类问题。5.1 把 terminated due to error 拆开来看我对线上积累的错误样本做过归类发现高频原因集中在四类错误类型具体表现出现频率模型输出格式不合法模型明明接收到输出 JSON的指令却返回了普通文本或者 JSON 截断无法解析很高工具调用异常工具接口超时、返回数据格式与预期不符、权限校验失败很高上下文超限长任务执行中累积历史轨迹加上工具返回的大段数据单轮请求超过模型上下文上限中等外部依赖故障上游 API 限流、数据库连接异常、第三方服务不可用中等看到这些错误很多人的第一反应是优化模型调用。但我的经验是大多数 termination 错误不是模型的问题而是 harness 层缺少错误恢复机制。模型本身是有能力从错误中恢复的关键在于你有没有给它恢复的机会和机制。5.2 让 agent 学会自救从 fail-fast 到 fail-retry 的改造我早期设计的 agent 循环很脆只要某一步工具调用抛异常整个任务直接终止把错误抛给用户。现在回头看这是最典型的工具式思维——把 agent 当成了普通程序程序抛异常就应该终止。但伙伴式 agent 应该具备遇到问题不慌张、自己找路走的能力。改造的核心是给模型的每一步决策提供结构化错误信息并允许它重新决策。下面是我常用的黄金规则工具调用失败时不要只返回error要返回结构化的错误详情失败原因、错误类型超时/校验失败/权限不足、可能的补救建议、是否值得重试。模型看到错误后应该被允许选择三条路之一换一组参数重试、改用其他工具、向用户澄清。只有当三条路都不可行或者重试次数超限才允许任务终止。每次重试都要有退避策略。工具超时后立刻重试往往还是超时间隔几秒甚至指数退避再试成功的概率要高得多。设定最大重试次数我通常设 2-3 次超出后进入人工兜底或降级处理分支而不是无限循环烧 token。这里的关键不是机械地加重试而是让错误信息成为模型下一步决策的输入。模型是具备推理能力的它拿到接口超时服务端可能过载和接口返回 403疑似权限失效这两种错误时会采取完全不同的后续行动。如果你只是把异常堆栈丢给它它也只能懵。5.3 可观测性没有轨迹审计就没有 agent 运维把 agent 当作伙伴之后还有一个必须补上的能力就是可观测性。你不可能用一个黑盒去服务用户。我在生产环境里要求每个 agent 任务都必须产出完整的决策轨迹记录包括每一步的输入上下文摘要、模型决策结果、选中的工具与参数、工具返回摘要、校验结果、耗时和 token 消耗。这套轨迹有三层价值。第一层是线上问题定位——用户投诉时可以直接回放整个决策轨迹找出是哪一步决策出了问题。第二层是数据飞轮——积累大量成功轨迹和失败轨迹之后可以用来做评测集、微调数据、prompt 优化依据。第三层是安全审计——确保 agent 没有在用户不知情的情况下执行敏感操作。轨迹记录的成本也不低每一步都存完整对话记录会非常占空间。我的做法是分层存储完整轨迹存冷存储对象存储或归档库按任务 ID 可检索近期的精简轨迹只存关键动作摘要存热存储方便快速查看。5.4 安全护栏工具权限最小化与敏感操作管控说到agent 安全很多人想到的是防止模型输出违规内容但工业界更紧迫的是工具权限的失控风险。当 agent 具备自主调用工具的能力后它可能在用户没有明确确认的情况下调用了删除付款发送这类高危操作。我在一个项目里就出现过一次agent 为了完成整理订阅列表的任务居然触发了退订接口——好在接口本身有权限校验拦住了。我的安全实践包含四条铁律工具权限最小化每个 agent 只挂载完成业务目标所必需的工具高危工具默认不开放确需开放时必须走人工审核流程。敏感操作二次确认执行删除、支付、发送消息、修改关键数据这类操作前agent 必须先生成操作确认请求发给用户用户点击确认后才继续。输出内容护栏模型生成用于展示给用户的内容必须过内容安全过滤器防止诱导违规、恶意代码、隐私泄露等风险。全链路审计所有工具调用无论成功失败都必须记录到审计日志包含调用者任务 ID、目标、参数、结果、时间戳。这是安全追溯的基础。这一节讲的内容偏工程治理但这些都是从工具到伙伴绕不开的功课——伙伴意味着更大的自主权更大的自主权意味着更强的约束和更完善的监督机制。想清楚这一点agent 项目在工业界才真正站得住脚。6. 评测、安全与框架选型2026 年做 agent 绕不开的三个现实问题最后聊一聊做 agent 的顶层设计问题评测体系怎么搭、框架怎么选、现在的生态应该怎么看。这些话题在网上讨论很多但大多是泛泛而谈我说说我的实操经验。6.1 评测没有评测集的 agent 项目等于裸奔Agent 评测比传统 NLP 评测难得多因为它没有一个标准答案。传统模型评测可以算 rouge、bleu、准确率但 agent 的核心指标是在真实环境里能不能把事办成。我的做法是维护一套分层评测体系。第一层是确定性评测。准备一批标准任务集每个任务有明确的目标和预期结果跑完之后检查是否达成。例如给用户 X 查询本月账单并生成摘要预期结果是账单数据准确、摘要包含关键项。这一层保证的是 agent 的基本完成能力。第二层是过程质量评测。任务完成了但完成得是否规范我关注四个指标步骤成功率每一步工具调用是否成功、平均步数完成任务是否绕路、token 成本单位任务消耗、延迟端到端耗时。这四个指标直接决定生产可用性。一个任务跑了 20 步才完成哪怕结果是对的线上也扛不住成本和延迟。第三层是对抗与边角评测。故意构造异常场景接口超时、用户输入模糊、工具返回脏数据、多步任务中途状态丢失。这一层测的是 agent 的韧性和兜底能力。评测集建立之后要持续积累线上失败案例定期补充进任务集。参考 AgentBench、GAIA 这类公开 benchmark 的思路是好的但一定要基于自己的业务造题——公开 benchmark 验证的是 agent 的通用能力你自己的评测集验证的是它在你业务里能不能活下来。这两个都必须有。6.2 框架选型按团队和场景选别按热度选主流的 agent 框架有哪些这个问题我几乎每周都会被问。说实话框架之间的差异远没有宣传里说的那么大更重要的是框架的编排范式是否匹配你的业务。下面是我对这些框架的实际使用感受框架编排范式适合场景主要注意点LangGraph显式图/状态机流程复杂、需要精细控制学习曲线较陡概念多但工程化能力最强AutoGen / AG2对话式多 agent多 agent 协作研究型项目动态对话逻辑较灵活但可控性较差CrewAI角色化多 agent快速原型、轻量业务上手快复杂状态管理偏弱Semantic Kernel插件化框架微软生态、企业集成和 Azure 生态绑定较深Spring AI注解式集成Java 技术栈、传统企业对 Java 团队友好生态相对年轻扣子 / Dify低代码平台非技术同学快速搭助手适合 MVP深度定制受限Google ADK模型驱动编排JVM 系、Kotlin/Java 场景新的框架资料较少我的选型建议很简单如果你的团队主要是 Python 工程师、业务流程偏复杂、需要断点恢复和人工审批节点LangGraph 是当前最稳的选择。如果团队是 Java 栈、要快速集成到现有 Spring 体系里Spring AI 值得认真看不必因为它不够热就跳过。如果是产品经理想自己搭个 demo 验证想法扣子这类低代码平台完全可以先跑起来但别指望它支撑复杂的生产逻辑。还有一个经常被忽略的判断标准是否需要长时运行与断点恢复。伙伴式 agent 的任务可能持续很久中间可能中断、需要恢复、需要人工介入。这种场景下框架对 持久化状态 的支持能力是第一优先级。我目前的经验是LangGraph 的 checkpointer 机制和显式状态管理是几个框架里最成熟的。6.3 2026 年国内的 agent 生态观察与中台化趋势从这两年的行业观察来看国内 agent 产品正在走向中台化。很多团队不再从零造一个 agent而是基于公司内部的 agent 中台做配置。这种模式对业务的帮助很大工具注册、权限管理、可观测性、评估体系都在中台里统一建设业务方只需要关注提示词和流程编排。但中台化也带来一个新的问题过度标准化可能会限制 agent 的深度发挥。一些业务团队拿到中台后习惯性地把 agent 用回了流程图自动化的老路子——这其实是在开倒车。我始终认为无论你用中台还是自研核心的认知不能丢agent 的价值在于目标驱动 自主决策 记忆积累 自我修正这套范式的组合而不在于你用了哪个框架、挂了哪些标签。扣子这类平台的兴起让搭 agent变成了一个低门槛操作这是好事因为更多人可以快速验证想法。但真正进入生产环境的时候你会发现决定成败的还是那些反直觉的深水区记忆的污染与消解、工具的权限与安全、错误的恢复与重试、评测集的持续积累。这些没有捷径只能一个个踩过来。最后再分享一点我的个人体会。做 agent 这一年多我最深的感受是不要把一个 agent 当作一个功能去实现而是要把它当作一个同事去管理。功能是确定性的输入输出可预测同事是目标导向的你给它清晰的目标、可用的工具、充分的背景、安全的边界它会在不确定的环境里自己想办法。从工具到伙伴的跃迁说到底就是你能不能接受这种可控的失控——在充分的约束和安全机制内允许模型自主地走出一条你没预想过的路径。接受这一点之后你的 agent 项目才算真正越过了那道分界线。这个系列下一篇我打算聊 agent 的评测体系与数据飞轮把这次只点到为止的部分展开。