企业官网建设流程全解析

最近又有人在群里问：你的 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 层负责，模型只需要遵守统一的输入输出协议。

第二是能力扩展缺乏边界。不分层的时候，每新增一种工具、一种记忆类型，你都要去改主 prompt，prompt 会越来越长，最终长到模型根本"读不进去"。分层之后，工具注册表、记忆系统、安全过滤器都是独立的模块，新增工具只需要在注册表里加一条描述，新增记忆类型只需要扩展记忆接口，主 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(goal=user_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 是低频写入、高度提炼的，主要用于指导"接下来应该怎么做"。如果混在一个表里，检索结果往往会很杂，相关性排序很难做好。

下面是我常用的三层记忆结构参考：

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" 拆开来看

我对线上积累的错误样本做过归类，发现高频原因集中在四类：

看到这些错误，很多人的第一反应是"优化模型调用"。但我的经验是，大多数 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 框架有哪些"这个问题我几乎每周都会被问。说实话，框架之间的差异远没有宣传里说的那么大，更重要的是框架的编排范式是否匹配你的业务。下面是我对这些框架的实际使用感受：

我的选型建议很简单：如果你的团队主要是 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 的评测体系与数据飞轮，把这次只点到为止的部分展开。