★ FEATURED ARTICLE 今年干了一件让自己挺意外的事在继续维护原来 AI 助手的同时我用团队内部代号为 OpenClaw 的框架一口气把业务切成 11 个专业 Agent从售后处理、内容审核到数据复盘全部立了独立的“岗位”。这篇文章就是来复盘我是怎么设计这些 Agent 的重点是我沉淀下来的设计模式以及上线后一个个血坑。如果你正在规划多智能体系统或者觉得“一个 AI 助手什么都能干但什么都干不好”那这篇应该能给你省下不少试错时间。我不打算讲太多建模理论OpenClaw 也不是什么公开框架它是我在项目里对“可控 Agent 运行时”的一套内部抽象。但设计模式是通用的工具路由、状态机、验收集、权限隔离、成本控制换任何框架都能直接用。1. 为什么是 11 个先把需求盘点清楚1.1 需求本质上是四类不是四十类我开始没有拍脑袋定数量而是先把过去一年的用户请求和机器人对话日志捞出来分了个类。分类完发现真实需求再五花八门也逃不出四类高频信息查询、内容生产、判断决策、跨系统操作。高频信息查询比如“我的订单到哪了”“额度还剩多少”本质是查数据库然后翻译成人类语言。这类需求占了大头适合做高并发、低延迟的轻量 Agent。内容生产比如周报初稿、活动文案、会议纪要不是查一下就完而是要理解上下文、生成结构化内容。这类需求对模型质量最敏感必须单独拆不然会被其他任务干扰。判断决策比如“这个用户投诉该不该升级处理”“这篇文章能不能过审”本质是一个带评分标准的分类问题。这类 Agent 不能只输出结论还要给出可追溯的判断链路。跨系统操作比如“帮我发起退款流程”“帮我建一个工单”涉及写操作。这类 Agent 的安全要求最高必须加人工确认和二次授权。把四类需求铺到对应的业务线上自然就形成了 11 个 Agent 的雏形。1.2 矩阵规划一个萝卜一个坑我按“业务线 能力类型”双维度做了矩阵11 个 Agent 的布局大概是这样序号定位核心能力典型工具记忆策略A1订单查询助手信息检索口径解释订单中心查询接口短期向量记忆A2售后处理 Agent判断问题归属、生成处理方案售后工单系统、退款预检短中期记忆A3物流补偿 Agent结合物流轨迹做赔付预估物流轨迹接口、补偿规则库中期记忆A4内容审核 Agent多维度规则审核、风险标记审核规则引擎、敏感词库长期记忆A5周报生成 Agent从项目数据生成结构化周报项目管理接口、模板库长周期记忆A6会议纪要 Agent长文本摘要待办抽取转写文件存储、待办系统短期记忆A7数据复盘 Agent按维度和指标做归因分析指标库、数据仓库查询长期记忆A8客服话术助手提供合规话术并标注依据知识库、用户标签接口长期记忆A9工单分类 Agent自动分类、定优先级工单系统、服务目录短期记忆A10营销文案 Agent生成文案并做多版本对比文案模板库、活动配置表短期记忆A11风险识别 Agent跨场景风险判断、事件上报规则引擎、风控事件接口长期记忆这张表的重点是数量控制。很多人一上来就按部门做 Agent一个部门一个最后做出 50 个没人维护的面条。我的经验是先按“能否独立验收”来判断一个 Agent 有没有自己的工具集、自己的状态边界、自己的验收标准。能独立验收才给它立岗。2. OpenClaw 的骨架Agent 元模型与配置抽象2.1 四层抽象把每个 Agent 变成标准件OpenClaw 的核心抽象是把一个 Agent 拆成四层模型接入层、工具层、状态层、策略层。模型接入层不管业务管的是路由什么场景用什么模型成本贵的模型只给核心判断用普通查询走轻量模型。这一层必须做成网关而不是让每个 Agent 自己配模型地址否则后面 11 个 Agent 模型一变改到崩溃。工具层是 Agent 唯一的“手”所有外部能力都封装成工具函数。工具必须有 Schema 声明包括参数格式、调用权限、风险等级不声明的一律不暴露给 Agent。状态层管的是会话和记忆。每个 Agent 都有 session、短期缓冲、长期向量库但不同 Agent 的状态 TTL 完全不同。比如天气查询类会话半小时就过期售后工单类要保留整个处理闭环。策略层放“规矩”包括意图校验、工具调用次数上限、超时时间、脱敏规则、人工确认开关。这是 OpenClaw 最值钱的一层因为大模型天然不可控可控性全靠策略层兜底。2.2 配置化一个 Agent 一份 YAML最开始写 Agent 的时候我也习惯把逻辑全部写在 Python 代码里结果一个 Agent 的代码调优另一个 Agent 跟着出问题。后来改成配置驱动的思路每个 Agent 一份 YAML运行时统一加载。这是我在 OpenClaw 里做的第一个重构收益非常直观。一个典型的配置长这样agent_id: after_sale_agent display_name: 售后处理智能体 model: provider: internal-gateway model_name: llm-32k temperature: 0.2 memory: short_window: 20 summary_enabled: true long_term: vector_store tools: - name: query_order api: order.center.query risk: read - name: issue_refund api: finance.center.refund risk: write need_confirm: true policy: intent_gate: true max_tool_calls: 5 timeout: 30s refuse_template: default_refuse配置文件的意义不只是“不用改代码”而是把 Agent 变成了可以被评审、被测试、被版本管理的对象。团队里任何人要做新 Agent拿一个模板改两行就能跑通 Demo效率完全不一样。2.3 工具协议所有接口统一按钮工具层最容易踩的坑是接口风格不统一有人写 Python 函数有人写 HTTP 接口还有人直接让模型读数据库。OpenClaw 的做法是把工具全部收编成统一协议底层不管是什么对外都是 ToolSpec。tool_spec( namequery_order, description根据订单号查询订单状态, parameters{ order_id: {type: string, required: True, rule: r^\w{8,32}$}, user_id: {type: string, required: False}, }, scopes[after_sale, logistics], riskread, ) def query_order(order_id: str, user_id: str ) - dict: ...统一协议带来的好处是 Agent 不用关心工具内部实现只要能拿到标准参数。更重要的是权限控制可以集中做同样一个query_order工具售后 Agent 能用营销文案 Agent 就不能用。3. 三个基础设计模式工具路由、状态机、记忆分层3.1 工具路由模式别让模型自己拍板调函数说到工具调用很多人第一反应是把所有工具函数直接给模型让模型自己选择。这个思路在大模型演示里看着很爽到生产环境就是灾难。原因很简单模型对工具的理解是概率性的不是确定性的尤其是工具多到一定程度以后模型选错工具、传错参数的概率会明显上升。OpenClaw 在这个问题上引入了意图网关模型的工具调用请求必须先经过意图网关校验校验通过才真的执行工具。做法是这样先把用户原始输入做意图识别和实体抽取把“用户到底想干什么”和“用户提到了哪些关键参数”算出来然后再看模型请求的工具是否和意图匹配。def intent_gate(user_input, model_tool_call): intent classify_intent(user_input) # 比如 refund_request entity extract_entities(user_input) # 比如 order_id: 20240101... allowed_tool tool_policy[intent].allowed # 退款意图能用哪些工具 if model_tool_call.tool not in allowed_tool: return reject(工具与当前意图不匹配) if not validate_param(model_tool_call.args, entity): return reject(参数与用户输入不匹配) return allow(model_tool_call)这个模式看起来多了一次模型调用但换来的是工具误调用的概率从“随缘”变成“可控”。我后续 11 个 Agent 上线后事故里没有一个是因为工具调错被外部投诉的靠的就是这一层兜底。3.2 有限状态机模式把长对话拆成可回滚的流程长对话 Agent 最容易出的事故是什么跑飞。用户上来问退款模型聊到一半突然开始给用户讲公司历史或者把售后流程和工单流程混在一起。这本质上是因为模型把整个对话当成一个“无限自由流”没有阶段概念。我的方案是给 Agent 画有限状态机每个会话只允许在业务流程定义好的状态之间流转。以售后 Agent 为例当前状态触发事件下一状态动作initial识别到订单查询意图order_confirmed调用查单工具、展示订单信息order_confirmed识别到退款意图且订单符合条件refund_review校验权限、进入退款预检refund_review预检通过completed调用退款工具、发送回执refund_review预检不通过或需要人工escalate_to_human生成转人工任务、保留上下文任意状态用户连续否定或超时closed清空短期缓存、写摘要OpenClaw 在每个会话初始化时读取状态机定义每次用户消息进来后先判断允许的转移路径不允许的直接拦下。你别觉得这限制了大模型的能力它限制的只是模型的随意性业务上每个状态内部的自由表达还是完全保留的。这套机制还有个额外好处能回滚。用户说“抱歉我不想退款了”状态可以直接从 refund_review 回到 order_confirmed而不是让模型自己脑补怎么处理。3.3 记忆分层模式短期、中期、长期各管一摊Agent 的记忆不能只有一个“聊天记录”变量越到后面越会炸。OpenClaw 的记忆模块做了三层短期记忆存最近会话里最具体的信息比如订单号、用户 ID、刚才用户表达的情绪。用 Redis List 加 TTL通常一个会话最多保留 20 到 40 条超过就把最早的踢掉。中期记忆是结构化的会话摘要。每过 5 轮对话或每次状态机状态跳转时让模型把前一段对话压缩成 200 字以内的摘要。这样长对话永远不会从第一条扯到第一百九十九条模型看到的永远是最新摘要加最新几轮。长期记忆存在向量库里存的是用户画像、历史偏好、历史处理结论。注意长期记忆不能自动写必须经过策略层审核只有明确的事实比如“该用户已有三次退款记录”才能入库模型的主观推断一律不存。用 OpenClaw 写记忆策略时我会在 Agent 配置里分别指定三层记忆的读写权限。有些 Agent 只有长期读写没有短期查询权限反而从设计上就避免了“跨 Agent 偷看隐私”的嫌疑。4. 多智能体协作主管、专家组与共享记忆4.1 主管-工人编排让调度变得可预测11 个 Agent 之间不可能完全不交流。以客服场景为例一个客诉进来先由客服话术助手判断问题类型如果是物流问题就派给物流补偿 Agent如果涉及退款就要把售后处理 Agent 拉进同一个工单上下文。OpenClaw 里的协作我用的是主管-工人模式而不是自由多 Agent 对话。自由对话看起来酷但两个模型你来我往很容易聊到失控且 token 消耗是线性增长的。主管 Agent 的职责很单一拆解任务、派给负责的工人 Agent、回收结果、向用户汇报。它不负责深度理解问题也不需要调用任何行业工具就是一个纯调度器。工人 Agent 只处理自己领域的问题拿到任务后直接在自己工具集里解决然后把结果固定成结构化字段返回。这种模式的最大的优点是每个 Agent 的验收边界是稳定的。主管好不好看它有没有派错人工人好不好看它在自己领域的任务上表现稳不稳。问题一出现能立刻定位到谁身上。4.2 专家组仲裁能打分的多 Agent 才是好多 Agent还有一些场景单一 Agent 判断不够稳需要让多个 Agent 背对背出具结论再合成最终答案。我在内容审核和风险识别场景里做了专家组模式三个相同定位但独立初始化的 Agent分别对同一段内容做判断各自输出风险等级和依据。汇总层拿到三个结果后不搞“少数服从多数”而是做加权打分的规则仲裁每个 Agent 的风险等级映射为分数再叠加预估置信度超过阈值才出最终结论否则转人工。仲裁逻辑要考虑覆盖分歧。三个 Agent 不会一模一样它们很可能一个判高、一个判低、一个踩中线。OpenClaw 的仲裁层会把分歧最大的样本自动回流到标注集里作为后续调整提示词和阈值的数据基础。这个过程我称之为“把模型分歧当成免费标注员”。4.3 共享记忆中心Agent 之间传话的通道多 Agent 协作里最容易被忽略的是共享上下文。主管把任务派给工人之后工人不能只看一句话还需要知道前面的对话脉络、用户已经提供的信息、其他 Agent 已经得出的中间结论。OpenClaw 的做法是引入共享记忆中心以工单 ID 或者会话 ID 为粒度把跨 Agent 的上下文写到一个统一的存储里。写入的 key 按命名空间隔离agent/{agent_id}/sessions/{session_id}/state agent/{agent_id}/sessions/{session_id}/summary agent/{agent_id}/tasks/{task_id}/result不同 Agent 可以读共享 session 里的基础上下文但只有负责该流程的 Agent 才能写。写操作也必须走工具层不能浏览器直连数据库。这里有个教训共享记忆不要做成一个大杂烩。Agent 之间传上下文只能传经过结构化的结果字段比如“订单已确认”“物流已延误”“用户同意升级处理”不能传原始全文。原始全文意味着每个 Agent 都要重新处理一遍信息既浪费 token又容易造成上下文污染。5. 从 0 到 1 搭出 11 个 Agent 的落地路径5.1 先把基座跑通再谈数量我不建议一上来就铺开 11 个 Agent我自己是分三步走完的。第一阶段只搭一个全场景基座一个主 Chat Agent挂上会话管理、工具网关、基础权限、日志链路。这一个 Agent 不强求业务能力只求“能聊、能翻车、能追责”。这一阶段的核心产出不是功能而是观测体系得能看清楚模型每一步调用了什么工具、每轮消耗了多少 token、用户在哪个状态流失了。第二阶段才把基座按业务拆成专用 Agent。每个 Agent 不是简单换个系统提示词而是重新配置工具集和状态机。我把一个售后 Agent 拆给物流补偿 Agent 时给后者新增了两个物流轨迹工具同时从工具列表里删掉了退款相关操作权限。这个“权限随拆分下沉”的动作是最容易出涟漪效应的一定要用配置中心统一管起来。第三阶段是给每个 Agent 建验收集。OpenClaw 支持在 Agent 配置里绑定一个测试集里面是 50 到 200 条历史真实问题样本每条标注了正确答案和期望的工具调用链。推荐每一版发布前都跑一遍没跑过测试集的 Agent 不允许上线。5.2 工具授权表Agent 的能力边界一念之间我还是建议把所有 Agent 的工具授权提前整理成一张表不然到后面根本管不住。以下是我当时上线前的部分授权表Agent可读工具可写工具需人工确认的操作订单查询助手订单中心、物流查询无无售后处理 Agent订单中心、工单系统工单创建/更新退款物流补偿 Agent物流轨迹、补偿规则库补偿单创建超过阈值补偿内容审核 Agent审核规则、敏感词库审核结果写库高风险判定风险识别 Agent规则引擎、用户标签风险事件上报高风险上报这张表看着简单排查问题的时候极其好使。某个 Agent 被投诉“越权查了不该查的数据”直接按表查它有没有对应的读工具权限即可不用翻代码。5.3 灰度上线老系统始终是安全垫11 个 Agent 不可能一次性全部上生产。我采用的策略是影子模式新 Agent 先在线上接收真实请求但只做“预测”结果不直接生效而是落到一个比对库里跟人工处理结果做对比。比如内容审核 Agent 在影子模式里跑了一周每天把它的审核结果和人工审核结果做一致性比对。一致率稳定到 95% 以上才打开真实审核按钮。哪怕打开真实按钮之后高风险内容仍强制转人工绝不交给模型一锤定音。“安全垫”这个词不是套话。我见过太多 Agent 项目把系统提示词写得天花乱坠一上线就被真实世界的脏数据打爆影子模式能让这些脏数据在可控范围内先被消化。6. 上线后最痛的五件事6.1 工具幻觉模型编了一个不存在的参数值第一个大坑来得很快。售后 Agent 在处理一个订单退款时模型自己脑补了一个订单号看起来格式和真实单号一模一样但根本不存在。结果工具层拿来查订单自然查不到Agent 就不停重试反复报错还把错误原因模棱两可地丢给用户说“系统繁忙”。排查链路是这样的先在日志里定位到模型请求工具时的入参发现订单号跟前端传来的订单号完全对不上。根源是大模型在生成工具调用参数时会把用户消息里没出现过的信息“补全”。修复措施有两层外层是意图网关加参数回填校验要求工具参数必须来自实体抽取结果而不是模型生成内容内层是给每个 Agent 加一句规则——参数不确定时必须反问用户不允许猜测。这两层叠下去工具幻觉从偶发事故变成了极小概率事件。6.2 上下文污染多轮对话被无关内容挤爆第二个坑是在会议纪要 Agent 上暴露的。这个 Agent 要处理的文字很长用户还会中途插入几句“刚刚那段不是重点”之类的口语废话。大模型分不清哪些是内容、哪些是态度表达全塞到上下文里结果纪要越来越偏。根因是模型把所有消息当成同等权重的输入。修复方案是 OpenClaw 的上下文清理层对话进入上下文之前先经过一个修剪模块把意图以外的闲聊、无关重复、纯语气词单独剥离只把有效业务内容提供给大模型。同时在状态机里加了一个“内容修正事件”让用户可以在任意轮次补充“以上XX不记录”触达后立刻将该内容从短期缓存里标记为失效不让它参与后续摘要。6.3 死循环Agent 反复调用工具不收敛第三个坑也够吓人的。某天凌晨工单分类 Agent 因为一个非常规格式的工单描述触发了一个 bug一直在“调用分类工具→结果置信度过低→重新分类→再调用工具”之间打转一个工单烧掉了平时二十多倍的 token整整循环了四十多分钟。后来一查就是没配 max_tool_calls 的锅。很多框架默认允许模型无限调用工具模型在“不确定”状态下会反复尝试。OpenClaw 的策略层后来强制加了三个默认值单轮工具调用上限默认 5 次工具结果置信度低于 0.4 不再重试直接转人工连续两次调用相同工具且参数相同直接终止并提问。这套组合拳下来死循环基本绝迹。还有一个经验不要相信模型“会主动承认自己卡住了”。模型永远会把当前动作描述成理性决策哪怕它已经在循环。所以停止条件不要靠模型自觉要靠策略层硬性拦截。6.4 权限越界上层模型“借用”了不该用的工具第四个坑比较隐蔽问题出在共享工具仓库。我们有个 Agent 能导出最近一周的用户访问日志本来只有风险识别 Agent 能用。结果某次主管 Agent 在处理用户投诉时为了“全面了解情况”居然调用了这个日志导出工具把一堆敏感字段拉了出来还展示给了终端用户画面。这就是工具层权限没做隔离导致的。OpenClaw 工具协议里的 scopes 字段解决不了动态权限问题因为主管 Agent 在运行时确实能接触到风险识别 Agent 的工具列表。后来我把所有 Agent 的工具列表做了运行时过滤每个 Agent 只能看到自己 scopes 内的工具物理隔离掉“借用工具”的可能。这一个改动涉及的代码量不大但安全性提升是质变的。6.5 token 成本失控11 个 Agent 同时跑起来账单先崩最后一个坑不报错但比报错更让人肉疼是成本。11 个 Agent 都在生产环境跑之后每天 token 消耗一度是预估值的 3.2 倍。复盘发现三个地方烧钱第一所有 Agent 都用的旗舰模型哪怕“查订单状态”这种一眼出结果的活儿也走大模型第二多智能体协作场景里主管 Agent 把完整工单全文发给工人 Agent一个工人 120 元 token 的调用七个工人就是 840 元信息还大量重复第三上下文窗口设得过大每轮对话都把全部历史塞进去重新计算。这三个问题的解法分别是小任务路由到轻量模型只有关键判断才走旗舰模型工人 Agent 之间只传结构化抽取字段不传原始全文上下文窗口按状态机阶段动态收缩退出某个状态后该状态细节立刻被摘要替代不再参与 next token 计算。调整之后日成本基本回到预估线附近。7. 现在回头看哪些模式留下哪些其实是过度设计7.1 真正留下来的是“业务边界 策略兜底”现在回看这 11 个 Agent 的设计真正让我有信心的是两件事业务边界和策略兜底。业务边界指的是每个 Agent 必须有清晰的角色定位可以使用“这个 Agent 服务谁、解决什么、不解决什么”一句话讲清楚。边界模糊的 Agent后续无论你怎么优化提示词稳定性都很难起来。策略兜底则承担了所有不确定性兜底意图网关、工具调用上限、权限过滤、人工确认这些机制压住了模型失控带来的大部分风险。专业 Agent 设计的核心不在于你用了多强的模型也不在于你接了多少个工具而在于你是否愿意从代码逻辑层面去约束一个大模型。约束力越强Agent 才越能稳定创造价值。7.2 被我亲手删掉的设计全面自由对话我最早构想的协作方案是两个 Agent 之间自由对话任意 Agent 都能向任意 Agent 发起请求整个系统看起来像一个有机体。但这个设计在测试阶段就被我自己毙了。自由对话意味着协同路径不可枚举一旦路径不可枚举你就没法做评测出故障也没法固定证据链。后来换成了固定工作流 有限跳数主管负责派发工人负责执行需要跨域协作时只能通过主管中转且总链路跳数不超过 3。这个设计的直接观感是没那么“酷”了但换来的是可观测、可测试、可回滚这些才是商用的底线。7.3 最后分享一个最实用的微设计统一拒绝模板如果你从这篇里只带走一个小技巧我建议是给每个 Agent 配一个“拒绝模板”。模板不是简单的“我不能帮你”而是包含三层拒绝原因、替代路径、升级入口。用 OpenClaw 的话说每个 Agent 的配置里留一个 refuse_template 字段。比如售后 Agent 无法处理金额超过阈值的退款时输出逻辑是“这笔退款金额超过我的处理权限已经为你生成人工工单 W12345客服会在一个工作日内联系你目前进度可以随时查询。”同样的模型有这条模板和没有这条模板用户体验是两个完全不同的档位。读者你自己接 Agent 的时候千万别忘了这个最小的兜底。
阅读完成 · 觉得有帮助？
