OpenClaw 企业微信实战：双 Agent 怎样跑进真实业务？
我在一个匿名跨境物流场景里，把客户 Agent 和供应商 Agent 接进企业微信。本文不讲安装捷径，只讲选型、Agent/Skill 拆分、确定性脚本、交接与真实失败。
先给答案：OpenClaw 能不能进入企业，不取决于它会不会聊天，而取决于你有没有把业务入口、Agent 角色、Skill 能力、确定性动作、权限和人工接管拆开。
我在一个匿名跨境物流场景里，把两个 Agent 接进了员工原本就在使用的企业微信群：客户 Agent 接收并补齐询价，供应商 Agent 处理供应商匹配、报价协作和结果回传。它已经进入真实业务运行，但我不会在这里公开客户身份、地点、业务规模、费用或经营结果。本文只讲生产运行事实、可复用方法和我自己踩过的坑。
这不是一篇 OpenClaw 安装教程。真正决定能不能上线的，往往发生在安装完成之后。
为什么选择 OpenClaw：先看端面，再看可控性
有人问我：已经有 Codex、Claude Code 或其他更聪明的工具，为什么还需要 OpenClaw？
我的选型顺序一直是三步。
1. 客户在哪干活，AI 就得接到哪
这个场景里的员工长期在企业微信里工作。让他们为了 AI 迁移到一个新后台，等于先制造一轮采用阻力。所以端面不是技术偏好，而是业务约束。
OpenClaw 对我最直接的价值，是让我能把 Agent 接到现有工作入口，同时保留自己的工作区、Skill、脚本和数据层。现在企业微信团队也维护了 OpenClaw 官方插件，但“能接入”仍然只代表入口打通，不代表生产系统已经成立。
2. 谁为结果负责，确定性就压在谁手里
更聪明的模型不一定更适合直接控制生产动作。需要理解、判断和选择下一步的工作，可以交给模型；涉及写入、去重、状态变更、金额或数据准确性的动作，必须落到确定性脚本和数据库约束里。
我越来越确定：不要让提示词承担数据库本应承担的责任，也不要让模型承担组织里没有人愿意承担的责任。
3. 最后才比较模型聪明程度
当业务边界、校验标准、知识和脚本都补齐后，很多日常任务对模型能力的要求没有想象中那么高。先把系统设计清楚，再做模型分层，通常比一开始就把所有请求交给最强模型更稳。
生产架构：五层，而不是一个万能 Agent
我把当前系统拆成五层：
| 层 | 负责什么 | 不应该负责什么 |
|---|---|---|
| 企业微信端面 | 接收员工消息、保留原工作习惯 | 决定业务规则 |
| Agent | 承担岗位视角、理解当前节点、编排跨能力流程 | 直接实现所有细节 |
| Skill | 封装可独立理解、测试和升级的业务能力 | 偷偷改变其他 Skill 的状态 |
| AGENTS.md 与作业规范 | 声明 Agent 间怎样协作、允许调用什么、何时停止 | 保存大量易变业务知识 |
| 确定性脚本与数据库 | 写入、去重、锁、状态变更、校验和审计 | 处理需要语义理解的开放判断 |
客户 Agent 和供应商 Agent 不是为了显得“多 Agent”而拆。它们对应两种不同的业务视角、知识和动作边界。只有当一个角色需要独立上下文、独立工具或独立责任时，我才会增加 Agent。
Agent 和 Skill 怎么划：我现在用三条规矩
规则一：Agent 按角色和责任拆
一个 Agent 对应一个需要长期保持的岗位视角。它知道自己服务谁、对哪一段流程负责、什么时候必须转交给另一个 Agent 或人。
规则二：Skill 按可独立验证的能力拆
如果一块能力能单独输入样本、检查输出、升级版本，它适合做成 Skill。比如字段标准化、业务知识检索、供应商候选匹配、报价材料整理。
如果只能通过“整个系统好像跑通了”来判断对错，这个 Skill 多半拆得太大。
规则三：业务知识采用渐进式披露
行业知识不能每次全部塞进上下文。我的做法是先让一个知识 Skill 根据场景返回需要阅读的参考文件，再由调用方按需读取。两个 Agent 可以共享知识入口，但不需要每次加载全部材料。
这也让知识和架构分开：岗位知识变化时更新参考文件，不必重写整套 Agent 协作关系。
第一版为什么被我废掉
第一版的问题不是完全不能跑，而是太依赖一段越来越长的提示词：业务规则、流程顺序、异常处理和输出格式混在一起。每增加一个例外，旧逻辑就可能被挤掉；表面上是在“调模型”，实际是在用自然语言维护一套不可测试的程序。
我最后把它废掉，重新做了三件事：
- 从岗位名称回到真实业务动作，重新画触发、输入、判断、写入、交接和验收；
- 把可判断的工作交给 Agent 和 Skill，把必须稳定的动作压进脚本与数据库；
- 把跨 Agent 协作和停止条件显式写出，不依赖模型临场猜测。
这次失败让我确认：Agent 项目如果一上来就在提示词里堆规则，往往说明业务还没有被拆明白。
生产里最危险的坑：模型误判失败以后重试
我在双 Agent 接线时撞过一次重复写入。第三方接口已经完成了动作，但模型没有正确解析返回结果，于是把它当成失败继续重试。提示词里写“不要重复调用”并不能可靠解决这种问题。
我后来用了三层防护：
- 业务幂等键与锁： 同一个业务 key 再次进入时，直接返回已有结果，不再请求第三方；
- 多解析器兜底： 主解析失败时还有备用解析路径，避免把“看不懂响应”误判成“服务端没执行”；
- 明确退出码： 成功、服务端拒绝、网络或解析失败、参数错误分别返回，不让模型自行解释模糊状态。
判断标准很简单：如果服务端没有 find or create 语义，调用方就必须自己保证幂等。凡是必须执行的防护，都应该变成模型只能调用的脚本，而不是一段它可能忘记遵守的提醒。
人工接管不是最后兜底，而是正式节点
我不会让 Agent 在以下情况继续猜：关键字段缺失、规则冲突、权限不明确、动作不可逆、外部承诺风险高，或者无法确定应该由哪个 owner 拍板。
一次可用的接管至少要带上：
- 原始请求和已经确认的字段；
- 使用过的知识来源与版本；
- 已执行动作及结果；
- 停止原因和风险；
- 需要人做的唯一决定；
- 决定完成后从哪个节点恢复。
只发一句“请人工确认”不是交接，它只是把上下文整理工作重新甩给了人。更完整的方法可以看人工接管清单和AI Agent human owner 指定方法。
哪些情况下，我不会推荐直接用 OpenClaw
OpenClaw 是底座，不是企业落地的默认答案。以下情况我会先停下来：
- 业务还说不清输入、输出和验收，只是想“先装一个 Agent”；
- 没有人能批准规则、权限和异常处理；
- 高风险系统只能给出宽权限，无法最小授权和回退；
- 现有 SaaS 已经能稳定解决问题，引入 Agent 只会增加维护面；
- 团队没有人持续处理日志、失败样本、知识版本和升级回归。
有时最重要的判断是：你不应该解决这个技术问题。 先问它是否真的限制了业务结果，再决定要不要继续投入。
上生产前，我会逐项检查这 12 件事
- 端面是否就是员工真实工作的地方；
- 每个 Agent 是否有独立角色、边界和停止条件；
- 每个 Skill 是否能独立测试；
- 知识是否按场景加载并带版本；
- 写入、去重和状态变更是否由确定性代码完成；
- 所有外部动作是否有幂等键；
- 权限是否从只读开始逐级开放；
- 异常是否能带完整上下文交给明确的人；
- 日志是否能回答“用了什么知识、做了什么动作”；
- 升级后是否回放失败样本；
- owner 不在线时是否有替补和降级路径；
- 团队是否知道什么情况下必须停止自动执行。
证据与公开边界
- 生产事实： 双 Agent 已进入匿名跨境物流场景的企业微信真实业务流程。
- 本文可复用部分： 端面优先的选型顺序、五层架构、Agent/Skill 边界、幂等、人工接管和上线检查。
- 真实失败： 第一版提示词架构被废弃；跨 Agent 写入曾因响应误判发生重复调用。
- 本文不公开： 客户身份、地点、人员、业务量、供应商或报价数据、成本、服务费用和经营结果。
- 不构成承诺： 这是一个具体场景的生产经验，不代表 OpenClaw 适合所有企业，也不代表使用同一架构会得到相同结果。
继续拆业务流程，可以看货代询价怎样拆成 AI 工作流；开始选权限边界，可用五级 AI Agent 权限矩阵；如果还没选定第一条流程，先用试点评分表。