夜雨聆风一个真实得有点乏味的剧本。
某公司的技术负责人看完一场 OpenClaw 的演示：一个 Agent 在本地跑起来，自己调工具、自己管会话、自己把多步任务拆开做完，架构干净得让人想鼓掌。当场拍板——"就基于它，给公司建数字员工平台"。
三个月后，项目卡在了一个谁都没在架构评审上提过的地方：财务部的数字员工能翻到销售部的会话记录。于是要补多租户；补完多租户发现没有角色权限，谁都能调用那个直连 ERP 的工具；补完权限，审计部门来了，问"上周三下午三点，是谁让这个 Agent 改了那张订单"——日志里有，但要花两天人工翻。
最后一算：省下的三个月，原样还回去了，还多搭进去两个月。
这不是团队水平的问题。开源 Harness 缺的不是功能，是设计假设——它的数据模型里从来就没有"组织"这个维度。而更麻烦的是，很多人以为换一个"正统企业级"的框架就能绕过去，结果撞上同一堵墙的另一面。
那这堵墙到底是什么？
一、"能跑"和"能用"之间，隔着的不是功能清单
先说清楚一个词。Harness（Agent 运行时框架）是这两年才被叫响的一个层：它不是大模型，也不是你的业务系统，而是夹在中间那层软件——负责让模型调用工具、管理会话状态、把多步任务编排着跑完。你可以把它理解成数字员工的"骨架和神经"：模型是脑子，业务系统是手脚，Harness 决定这两者怎么连、怎么协调。
OpenClaw 和 Hermes 是这两年最值得研究的两具骨架。我自己在这两个项目上做过 60 多篇源码级的拆解，结论很明确：它们的架构是一流的，但它们的架构假设，和企业要的东西是两回事。
OpenClaw 的产品定位写在它的第一行文档里——"跑在你自己设备上的个人 AI 助手"。它的控制面默认只监听本机地址，会话模型区分主聊和群组，但整个系统里没有"组织"这个概念：没有跨用户的租户边界，没有基于角色的权限矩阵。它的安全模型是"配对授权 + 不信任入站消息"——这是一种准入控制（决定"你能不能进来"），而不是权限分级（决定"进来之后你能碰什么"）。对一台单人使用的设备来说，这个设计是对的，甚至是优雅的。
Hermes 作为 OpenClaw 的下一代，工程成熟度明显更高：加了自我进化闭环（Agent 自己创建技能、自己整理记忆）、六档执行后端、十七个通道生态。但它的产品命题仍然写着 "The self-improving AI agent"——服务对象是"你"这一个人，不是"一个有 N 个部门、M 个角色、需要审计追溯的组织"。
这个差异，不是"功能多寡"的量变，是"设计假设"的质变。
而设计假设这东西，最坏的性质是：它不写在功能清单里，所以你在选型阶段看不见它。 你对着 README 打勾，每一项都打得下去；你跑一遍 demo，每一步都跑得通。它要到你把第二个部门接进来的那一天，才会显形。
那么它显形的时候，具体显在哪三个地方？
二、第一层：租户不是一个字段，是一个维度
企业级的第一条刚需，叫多租户隔离——说人话就是：多个部门、多个客户在同一套系统里跑，彼此的数据必须互相看不见。
听上去像是加一个字段的事：给每条数据打个标签，标明它属于哪个部门，查询的时候带上这个条件不就完了？
不是。而这一处的差别，决定了那份"省下的三个月"到底是省下的，还是借来的。
OpenClaw 和 Hermes 的存储层——会话、记忆、技能这三处——从设计的第一天起就没有"归属于哪个租户"这个维度。它不是"有这个字段但没启用"，是这个概念在数据模型里根本不存在。而一个数据模型里不存在的维度，你要补进去，不是加一列的事：所有的写入路径要重新决定归属，所有的读取路径要重新加上边界过滤，所有的历史数据要重新回填归属，所有的跨会话逻辑（记忆检索、技能调用）要重新验证会不会漏出边界。
补一个维度，等于重构存储层。 这是"改开源"和"从头搭"在成本上的分水岭：你以为你在做加法，实际上你在做地基置换——而地基置换的特点是，上面盖的楼越多，越贵。
这里可以给一把判断尺，比记住任何技术名词都管用：
看一个开源项目能不能做企业底座，别看它的功能列表，看它的数据表里有没有"我是谁的"这一栏。
有，说明设计者从第一天就想过"多个组织共用一套系统"这件事；没有，说明它从来只服务一个人——而这一栏，是补不进去的，只能重铺。
租户是地基。那盖在地基上的另外两层呢？
三、第二、三层：权限和审计，是"事后补必留漏洞"的典型
第二条刚需是权限体系（业内叫 RBAC，基于角色的访问控制）：谁能调用哪个工具、谁能看哪些数据、谁能触发哪个自动化任务。
它的难，难在它是一个横切关注点——这个词值得翻译一下：所谓横切，是指这件事没法被关在某一个模块里解决，它要像一根钢筋一样，同时穿过工具注册层、会话层、记忆层。你在工具注册的地方拦住了"实习生不能调用退款接口"，但如果会话层允许他把这个任务委托给另一个 Agent，或者记忆层把上次退款的凭证原样吐了出来，这道拦截就白设了。
横切关注点的通性是：事后加，极易留漏洞。 因为你只能想到你想得到的那些路径，而漏洞永远长在你没想到的那条路径上。这就是为什么"先上线，合规问题以后再补"在权限这件事上是最贵的一种拖延。
第三条刚需是审计留痕。这一层最容易被糊弄过去，因为几乎所有系统都会说"我有日志啊"。
日志不等于审计。这两者是两种完全不同的数据模型：
•执行日志 / 轨迹：为调试和训练设计的。它回答的是"这次跑成什么样、哪一步出错了"。Hermes 记录得相当完整的那套 trajectory，本质是给强化学习训练用的行为轨迹。
•合规审计：为追责和取证设计的。它回答的是"谁在什么时间对哪条数据做了什么操作"，并且要求这条记录不可篡改、结构化可查、能按租户和角色过滤。
拿前者当后者用，平时相安无事，出事那天你会发现：记录是有的，但它答不了审计员真正要问的那个问题。
到这儿，三层就齐了——租户、权限、审计。它们共同的性质是：都不在功能清单上，都是设计假设，都在数据模型的第一版里就已经决定了有没有。
于是很自然地，一个念头会冒出来：那我不用 OpenClaw 这类个人助手了，我去挑一个"生而为企业设计"的框架，不就绕开了？
而这个念头，比前面三层加起来更值钱，也更危险。
四、换个"企业级"框架，你会撞上同一堵墙的另一面
我们把主流的企业级候选摊开看。它们确实比个人助手 Harness 更适合做数字员工底座——但请注意每一个后面跟着的那半句：
•LangGraph（把 Agent 的多步决策显式画成一张状态图）是目前生产化验证最扎实的一个，连 Elastic 这样的公司都签了多年期协议。但它的可观测与治理能力（trace 里原生带租户和会话标识、能做成本归因）在配套的商业平台里——按用户按月订阅起步。
•CrewAI（按角色分工组队的多 Agent 框架）上手最快，两三个工程师日就能出 demo。但它的 RBAC 和不可篡改审计日志，在它的商业运营平台里。而且即便买了，社区里的讨论显示：完整的多租户场景，团队仍可能要自己补组织层。
•微软的 Agent Framework 框架本身开源、双语言、可完全自托管。但它的企业治理（统一身份认证、审计留痕、闲时不计费的托管调度）集中在 Azure 的托管服务里——自托管，等于放弃这部分开箱即用的治理能力，自己造一套等价的。
•厂商官方的 Agent SDK（Anthropic、OpenAI、微软三家）也一样：开源/免费的那部分，只覆盖"让 Agent 跑起来"；真正的治理——身份、审计、成本监控——都在各自的托管服务那一侧。
看出规律了吗？这些框架的企业级故事，普遍是"开源引擎 + 商业治理层"的组合拳。 引擎白送，治理收费。
而 Dify 把这件事推到了最极端，也最值得单拎出来讲——因为它踩的不是技术坑，是法务坑：
Dify 的社区版基于一份修改过的 Apache 2.0 协议。修改的那条内容是：未经书面授权，不得用它的源码运营多租户环境。也就是说，你想拿社区版包装成一个多部门/多客户共用的平台——这不是"功能没有可以自己写"，而是"你写了也可能违反许可协议"。企业要真正的多租户能力（多工作区管理、单点登录、集中访问控制、多因素认证），必须走它的商业企业版。
这是一条只有在选型阶段算 TCO（总拥有成本）时才躲得开的红线。等你二次开发做到一半才发现许可证不允许，退无可退。
所以真正的错觉不在 OpenClaw 身上。真正的错觉，在"开源"这两个字上——很多人默认"开源核心免费 = 企业能力免费"，而现实是：企业能力是这个行业统一的收费点。 有的框架把它锁在订阅里，有的锁在托管服务里，Dify 干脆锁在了许可协议里。
这条规律还有一个更隐蔽的推论：你在选型时评估的那个产品，未必是三年后还活着的那个。
OpenAI 这条线是最好的例子。它的 Assistants API 已经公告将在 2026 年 8 月 26 日从接口中移除；它的可视化编排工具 Agent Builder 和评测产品线，也将在 2026 年 11 月 30 日起在平台下线，官方给出的迁移路径是"要继续用代码维护的工作流，请迁到 Agents SDK"。两年之内，这条产品线的命名和边界变了三轮。 对一个准备用它承载未来五年数字员工的企业来说，这不是"新功能真多"，这是选型风险——而且它同样不写在功能清单上。
顺带说一个同样只在选型阶段致命的坑：AutoGen 系的谱系问题。微软原始的 AutoGen 现在已进入维护模式（只修 bug 不加新功能），微软自己都建议新项目不要基于它开工；社区分叉出了 AG2；微软官方的继任者是 Agent Framework（连 Semantic Kernel 也一并合并进去了，同样进维护模式）。这三支代码互不兼容。 选型的第一个动作，不是比较谁更强，是先问清楚你要落地的到底是哪一支——选错，等于选了一个已经被官方判了死缓的分支。
那么，既然开源躲不开、换框架也躲不开，还怎么选？
五、把问题换掉：先回答第 0 步，再谈选谁
我的建议是："要不要在 OpenClaw / Hermes 上改"这个问题本身，问错了方向。
真正该问的第 0 步是一个业务问题，不是技术问题：
你要建的，是"单租户内部工具"，还是"多租户 / 跨部门 / 跨客户的平台"？
这一个问题，就决定了个人助手 Harness 能不能进候选池。
如果是单租户——比如只给供应链部门内部十几个人用的一个效率工具——那么 OpenClaw / Hermes 的轻量架构、成熟的 Agent 循环、会话模型、技能机制，反而是效率优势而不是短板。这里我要诚实地把话说回来：一棍子打死它们是不对的，在这个场景里它们跑得比任何企业级框架都快。
但要附一个提醒：这类工具一旦后续要推广给更多部门，几乎必然要重构存储层。 所以在动手那天就该问自己一句——这个"重构窗口"，大概什么时候会到来？把它写进路线图，而不是等它变成事故。
如果是多租户——这是绝大多数企业数字员工平台的真实形态——那么个人助手 Harness 直接出局，剩下三条腿去挑：厂商官方 SDK、通用开源编排框架、完全自研。这三条腿怎么挑，取决于你的团队已经绑在哪个生态里、工程能力有多强、场景有多复杂，这是另一个话题。
但无论你最后挑了哪一条，够不够格做企业级底座的硬门槛，只有一条：
多租户隔离、权限体系、审计留痕、可观测性——这四项，是不是在架构的第一天就是一等公民，而不是上线后再补的合规补丁？
这把尺子的用法很朴素：拿它去问你正在评估的每一个框架、每一个供应商、每一个"我们自己搭"的方案。四项里但凡有一项的答案是"这个后面可以加"，你就已经知道账单会在什么时候寄到了。
顺着这把尺子还能推出一条采购纪律："编排框架"和"运维治理层"要分开做决策，不要指望一个开源项目单独扛住两件事。 选型会上真正该问的，不是"哪个引擎的 Agent 更聪明"，而是"这个引擎的官方治理层存不存在、成不成熟、许可条款允不允许我自建一套替代"。
说到这里，还剩最后一个问题没答：那 OpenClaw、Hermes 这些项目，就白研究了？
六、边界：它们最值钱的，恰恰是它们"没做的那三层"
恰恰相反。
它们的真正价值，从来不在"拿代码库改改就能上生产"，而在架构模式和实现参考：Agent 循环怎么设计、会话模型怎么隔离、多通道怎么抽象、技能机制怎么让 Agent 自己长出新能力——这些是这个行业里最好的公开教材之一，是"读"的价值，不是"改"的价值。
而它们提供的最贵的一课，恰恰是那三层缺失本身：
权限和审计要在数据模型的第一版就设计进去——哪怕你初期只有一个租户。
这条纪律，不是从任何一份企业级框架的文档里学到的，是从"没这么做的项目后来要付什么代价"里学到的。反例的教学价值，往往比正例高。
所以，如果你的团队正准备基于某个开源 Harness 开工，我建议把这条纪律直接写进架构评审的第一页：租户边界、角色矩阵、不可篡改审计日志，从第一版数据模型就在。 哪怕现在只有一个部门在用，哪怕它看起来像是在为一个还不存在的问题写代码——它就是地基，地基没有"以后再打"这个选项。
把前面六节串起来看一下推演链：
开源 Harness 惊艳但当不了企业底座（§1，因为它的设计假设是"服务一个人"）→ 差的第一层是租户，而租户不是字段是维度，补它等于重铺地基（§2）→ 差的第二、三层是权限和审计，它们是横切关注点，事后补必留漏洞，而"有日志"不等于"能审计"（§3）→ 但换去"正统企业级"框架也躲不开，因为企业治理能力是全行业统一的收费点，Dify 更是把多租户锁进了许可协议（§4）→ 所以选型的第 0 步不是"选谁"，是先分清单租户还是多租户，再用"四项一等公民"这把尺子过一遍（§5）→ 而 OpenClaw / Hermes 最值钱的，是它们用缺失教给你的那条架构纪律（§6）。
一句话收束：你能免费拿走开源 Harness 的代码，但拿不走它没有的那三层；而那三层，恰恰是"个人助手"和"企业数字员工"之间的全部距离。
下次再有人看完一场 demo 就想拍板，先请他回答第 0 步那个问题——单租户，还是多租户。
这个问题他答得越快，你越该追问一句：那第二个部门什么时候接进来？
关注【智链进化论】洞察 AI 前沿，解码实战逻辑，赋能供应链数字化的战略进化
