ARTICLE · 1002889
大厂面试官居然问:“openclaw不就是工程组合吗?有什么agent技术的创新”,我没反驳,只能说出几个点
近期在有小伙伴在一个大厂的的面试中，遇到了一个年轻面试官常提出一个挑战性议题：他问“现在有人认为 OpenClaw 就是是现有 Agent 能力的工程化堆叠，缺乏底层核心技术突破，文他你怎么看？”，面试者当场有点懵，也不知道怎么回，就只能灭有反驳说出一些基本的定义，然后顺便说一下自己的理解。话说回来，这就是需要我们去判断，最近出来的openclaw真的只是"工程组合吗"。我们先说下背景，在后面我们会说下怎么回答面试官的问题。
从一次安全事件说起
2024年第三季度，一家金融科技公司在测试自研Agent系统时，遭遇了一起典型事故。由于工具调用协议的JSON Schema定义存在细微偏差，模型错误理解了“查询余额”与“转账”的参数边界，险些在模拟环境中执行了非授权操作。这起事件揭示了一个行业普遍困境：Agent的能力越强，失控的风险就越高。而传统的硬编码工具定义方式，恰恰是主要风险来源之一。
正是在这种背景下，OpenClaw的走红显得意味深长。许多人将其成功简单归结为“对现有Agent能力进行了工程化整合”，甚至质疑其缺乏核心技术创新。但从安全架构与生态构建的视角重新审视，结论便截然不同。
主流方案的“阿克琉斯之踵”
先看一个清晰的对比。目前主流的Agent开发框架（如LangChain、AutoGPT的原生实现）普遍采用JSON Schema来定义工具接口。这套方案的逻辑很直接：将函数参数、返回值、调用约束全部写成结构化的机器可读格式。它的优点是精确，但缺点同样明显——脆弱。模型必须严格按照预设格式输出，一旦参数名拼写错误或类型不匹配，调用就会失败。问题的核心在于，JSON只是一个“参数表”，而非“说明书”。模型知道要传递什么字段，却不知道为什么要这么传，以及遇到异常该如何处理。
这就导致了一个反直觉的现象：工具的调用逻辑越复杂，JSON Schema就越冗长，模型反而越容易出错。前述金融公司的案例，本质就是这个问题——模型并非不聪明，而是缺乏对任务上下文的理解能力。
OpenClaw的逆向解法：从“参数”到“说明书”
OpenClaw的skill.md机制，正是冲着这个痛点设计的。它做了两件与传统框架完全不同的事：
第一，将工具定义从机器格式换成了人机混合格式。 Markdown天然支持自然语言描述、示例代码、注意事项和异常处理流程。模型不再需要死记硬背参数结构，而是可以通过“阅读说明书”来理解工具的意图、边界和使用技巧。举个例子，一个“发送邮件”的JSON Schema只会告诉模型“to、subject、body是必填字段”，但skill.md可以明确写明：“如果收件人地址不在通讯录中，请先弹窗确认”。后者显然更接近人类的协作方式。
第二，引入了元数据懒加载机制。 传统框架往往在启动时就将所有工具定义加载进上下文，既浪费Token，又容易造成干扰。OpenClaw的做法是让模型先理解用户需求，再动态匹配相关技能、按需加载详细说明。这就像一个经验丰富的专家，不会一开始就翻出所有手册，而是先听清楚问题，再去找对应的章节。
但这里有一个极易被忽略的代价：自然语言说明书虽然对模型友好，却对版本管理、自动化测试和权限审计提出了新的挑战。JSON Schema可以轻松进行diff对比、编写单元测试、利用正则进行静态分析。而Markdown的语义灵活性意味着，同样的功能描述，不同开发者写出来的差异可能很大，模型的理解效果也可能不稳定。这是OpenClaw生态未来必须面对的工程债。
安全不是“自觉”，而是“隔离”
回到文章开头的事故。如果那家金融公司使用的是OpenClaw框架，能避免吗？不一定，但它的风险控制路径确实更清晰。
OpenClaw的安全设计遵循一个核心原则：不信任模型的自我判断。具体体现在两层隔离上：
人在回路（HITL）：对于高危操作（如删除、转账、修改权限），必须经过用户手动确认。这不是技术妥协，而是架构上的主动选择——承认幻觉无法100%消除，因此用人的判断作为最后一道闸门。 沙箱执行环境：即便模型被恶意提示词诱导，试图执行“删除系统文件”这类指令，它的操作权限也被锁死在容器内部，无法触及宿主机。这与传统软件安全中的最小权限原则一脉相承，只是首次被系统性地引入Agent框架。
相比之下，许多自研Agent方案要么依赖模型的“自律”（例如在系统提示词里写上“不要做危险操作”），要么只做了简单的操作日志记录。前者形同虚设，后者只能事后追责，无法事中阻断。OpenClaw的贡献不在于发明了新的安全技术，而在于把分散的安全实践整合成了一套可复用的架构模板——这恰恰是当前最稀缺的工程化能力。
一个尚未解决的矛盾
然而，这套安全机制也引出了一个深层矛盾：HITL虽然安全，却会打断任务的连续性。设想一个场景：Agent需要在午夜自动处理一批邮件，其中两封涉及敏感操作需要用户确认——如果用户正在睡觉，任务就卡住了。OpenClaw目前的方案是让开发者自行定义“哪些操作需要确认、哪些可以自动执行”，但阈值设定本身就是一个难题。设得太严，自动化形同虚设；设得太松，安全防线名存实亡。
这其实暴露了一个更本质的问题：工程整合解决的是一般性问题，但边缘场景的权衡永远需要人的判断。 OpenClaw的价值在于提供了权衡的工具箱，而不是替你做出权衡。
对比生态位：OpenClaw、Dify与Coze
为了更清晰地定位OpenClaw的创新性质，我们不妨将其放在当前Agent开发工具的坐标系中进行对比：
可以看出，OpenClaw并非在算法层与这些工具竞争——它的模型能力可能并不比Coze强，它的工作流编排也不如Dify灵活。它的独特优势在于把Agent“塞进”了用户已经熟悉的聊天界面里，同时用skill.md大幅降低了工具贡献的门槛。这种“接入即用、贡献即写文档”的体验，才是它迅速走红的真正原因。
总结：工程整合为什么是硬核创新？
回到面试官的那句质疑：“OpenClaw只是把现有能力做了工程化整合，没有核心技术创新。”
这个观点的偏差在于，它默认只有算法突破（如新的模型架构、训练方法）才算创新。但在AI落地的现阶段，真正的瓶颈往往不在模型的智商，而在于：
如何让模型安全地操作真实世界（安全隔离、权限审计、行为回溯） 如何让非专家也能为AI贡献能力（从JSON到Markdown的门槛降低） 如何让Agent无缝融入人类的工作流（IM接入、交互低损耗）
OpenClaw在这三个方向上都给出了可复用的工程方案。它的skill.md定义了一种新的“人-AI-工具”协作协议；它的HITL+沙箱机制为行业提供了一个安全参考架构；它的去中心化接入方式降低了Agent的使用摩擦。
笔者的一个判断：这种方法的优势在于“低门槛、高安全、快接入”，非常适合个人效率工具和企业内部助手的场景。但在需要复杂状态管理、多步长时决策、高并发实时响应的工业级任务中（例如供应链优化、实时风控），它的轻量化设计可能成为瓶颈。届时，或许需要更重的编排引擎与它配合使用，而不是完全替代。
最后，留给读者一个开放问题：当skill.md生态足够庞大，各种技能的说明书之间存在冲突或重叠时，模型该如何裁决？这会不会催生出下一个创新点——一个“技能说明书的质量评估与冲突仲裁机制”？这个问题，目前还没有人能给出答案。