最近技术资讯里OpenClaw 2.0、AI 应用护城河、ClickHouse 智能体基础设施这几个词经常一起出现。单独看它们是三条内容线但背后其实是一个趋势AI 应用不再只是对话框而是由多个模型、多个工具、多次执行和大量运行数据组成的系统。OpenClaw 这类本地部署的 agent 框架开始把协作当作核心能力ClickHouse 则越来越多地被用在 agent 日志、会话记录和运行指标分析上AI 应用护城河的讨论也在提醒大家只接一个模型 API 做出来的功能很难形成长期竞争力。这篇文章主要面向正在做智能体应用、agent 工作流和数据分析基建的开发者我会按 Agent 层、应用层、数据层三个角度把这三件事拆开并给出能落到本地的验证路径。1. 先看 OpenClaw 2.0协作能力的前提是分工、授权和可控执行1.1 为什么“2.0 协作”会被单独拿出来说早期很多单 Agent 工具不需要太复杂的设计。一个角色、一段系统提示词、一块记忆区域基本就能完成问答、总结、简单信息检索。但任务一旦变长问题马上就暴露上下文越来越乱用户不知道 agent 下一步要执行什么前面的输出也可能被后面的对话覆盖。多个任务混在同一个会话里最后很容易出现“前面答对了、后面开始胡来”的情况。所以 agent 的协作能力本质上不是在聊天窗口里多拉几个角色而是解决几个工程问题任务由谁拆解由谁执行由谁确认。一个 agent 的输出如何稳定传给另一个 agent 作为输入。哪些上下文是共享的哪些上下文必须隔离。哪些操作允许执行哪些必须经过审批。一次多步骤执行之后如何回放整个过程。OpenClaw 2.0 被频繁讨论核心不是某个具体参数而是它把“协作”提到了版本重点的位置。从社区里流传的安装、配置、skill、active memory 这些关键词看它更像一个本地部署型、支持多模型接入的 agent 框架。这类框架的工程结构通常包含三样东西工作区、执行审批、长期记忆。这三样分别解决“在哪里干活”“能不能干”“干过什么”的问题。这里要提醒一句协作不等于把任务全部丢给 agent 自动跑。更稳妥的做法是先建立“分工”和“审批”机制让 agent 在受限范围内协作而不是一上来就追求全自动。1.2 本地部署先从目录和初始化入手别急着配模型按照社区常见部署方式OpenClaw 的本地安装一般会经历这几个阶段安装、初始化、配置模型、接入工具、验证任务。安装阶段要注意不同操作系统的路径差异。Windows 环境里工作区经常出现在类似C:\Users\administrator\.openclaw\workspace的位置Linux 环境里则可能是/root/.openclaw/。这类框架默认会把配置、审批文件、工作区都放在用户目录下的隐藏目录中而不是项目代码目录。我建议第一轮测试按下面这个顺序走完成安装和初始化不要跳过 onboard 或 setup 流程。先检查隐藏目录是否生成配置目录、workspace、审批文件是否齐全。再配置模型。模型配置至少要区分三样东西模型名称、API 地址、密钥或 token。用一个纯文本任务验证比如“介绍一下你自己的配置结构”不要执行任何文件操作。确认日志输出正常后再逐渐增加工具调用和文件读写。在 Linux 下可以用这组命令先看目录结构Windows 可以换成同样的dir命令ls -la ~/.openclaw ls -la ~/.openclaw/workspace cat ~/.openclaw/exec-approvals.json很多启动问题都出在目录缺失或者权限不足。agent 框架在启动时如果找不到 workspace可能不会主动报错而是到第一次执行文件任务时才失败。所以先确认基础目录比反复重装更有价值。1.3 exec-approvals、workspace、skill、active memory 分别在管什么这类本地 agent 框架里几个关键配置不是摆设。workspace 是操作沙箱。agent 的读文件、写文件、生成中间结果尽量都限制在这个目录里。不要把整个系统目录直接暴露给 agent。如果你只是做个人项目至少也要单独建一个工作目录避免 agent 在项目目录里随意创建文件。exec-approvals.json 是执行审批文件。它用来管理“哪些命令可以被执行、哪些命令需要确认、哪些命令直接拒绝”。有经验的人会把删除类命令、覆盖类命令、外发文件类命令都拉进审批清单。如果运行时看到类似legacy exec approvals exist at /root/.openclaw/exec-approvals.json的提示说明旧版审批配置需要迁移。处理方式是先备份旧文件再执行迁移或合并不要直接删除。skill 是可复用能力包。它的本质是把固定的工作流沉淀成提示词、脚本和参数定义。比如“生成项目周报”“整理会议纪要”“批量处理某个目录下的文件”都能封装成 skill。skill 的价值是让 agent 不再每次从头理解需求而是按固定流程执行。active memory 是跨会话记忆。真正的 active memory 不应该只是把历史消息全部塞进上下文。更合理的方式是定期把重要结论、用户偏好、项目状态写入外部存储在需要的时候再检索出来。现在很多 long-term memory 方案都会配合向量数据库、关系库或者分析数据库使用单纯靠上下文窗口解决不了长期记忆问题。这几个组件的关系可以这样理解组件常见目录或形式解决的问题我的建议workspace.openclaw/workspaceagent 在哪里操作文件和代码仓库隔离单独建目录exec-approvals.json用户目录下的 JSON 文件哪些命令可执行先备份再迁移不直接删skillskill 目录或配置固定流程复用把重复任务提前沉淀active memory记忆索引或外部存储跨会话长期状态定期压缩不全量堆上下文1.4 模型报错和审批迁移两个最常见的启动问题从近期热门搜索里能看到很多安装报错最典型的是两种。第一种是“安装后 agent 回复失败提示 unknown model”。比如配置里写了模型名称是deepseek但 API 服务端期望的模型名可能是deepseek-chat这类具体别名。还有可能是 API 地址少了路径、密钥配置错位、或者多个模型服务之间搞混了。排查顺序不要乱先确认模型供应商后台里的准确模型名称。检查 API 地址是否写完整有没有缺/v1或/api。检查密钥或 token 是否确实有效。用命令行或 curl 直接请求一次模型接口能通再回来看 agent 配置。如果直接调用模型接口没问题那问题基本在 agent 配置文件的字段映射上。第二种是审批文件提示。看到legacy exec approvals exist这类信息时先不要删文件。这通常是新版本引入了新的审批格式旧文件还存在系统希望转换。正确做法是先复制一份备份再用工具完成迁移。如果不知道迁移命令就先把旧文件内容读出来手动整理进新格式。在实际接入外部工具时还有一个容易忽略的边界渠道接入。比如想让 agent 接入微信、IM 或者其他聊天平台第一件事不是发消息而是想清楚授权边界。收到用户指令后agent 能访问哪些联系人、哪些群、哪些文件如果授权太宽一个 prompt injection 或者误操作就可能把消息发错对象。日志、审批、权限这些越早做越省事。2. 讨论 AI 应用护城河时真正要聊的是数据和流程2.1 “套壳”不是问题问题是没有使用门槛“AI 应用护城河”是个容易聊偏的话题。有人觉得调用大模型 API 做的应用都是“套壳”没有价值有人觉得产品交互好就能赢功能上线后立刻被复制。我的判断是早期用一个现成大模型快速验证需求完全正常几乎所有 AI 应用都会从“套壳”开始。真正的问题不是套壳而是做了几个月之后产品里有没有沉淀下别人拿不走的东西。通常有四种东西可以成为护城河私有数据和用户行为数据。用户在你的系统里产生的历史记录、偏好、审批意见、修改痕迹这些数据越积越多迁移成本就越高。业务工作流绑定。agent 不再只是回答问题而是嵌进了具体公司的采购、排产、售后、研发流程里。换方案意味着要改流程。成本和效率优势。你的 prompt 压缩策略、缓存策略、模型路由比对方更省 token长期就有价格空间。领域术语和评估集。团队长期积累了一批高质量测试用例知道哪些 prompt 会失败、哪些输出需要修正这是别人短期补不上的。只靠“我的系统提示词写得比你好”是守不住市场的。提示词太容易被复制数据和流程很难被复制。2.2 用三个问题判断你的 AI 应用有没有护城河设计产品时可以定期问自己三个问题。第一个问题如果明天把底层模型替换掉产品还能不能正常运转如果答案是不能说明业务逻辑和某个模型绑定太深。这里不是说要时刻准备换模型而是要知道哪些环节需要抽象。调用层换成统一接口评估集保持稳定业务逻辑不要散落在 prompt 里这样任何一个模型升级或涨价你都有切换空间。第二个问题用户使用产品越久沉淀下来的数据是否越多一个典型的反例是“问完即走”的聊天工具用户只是临时提一个问题没有收藏、没有修订、没有反馈产品对用户一无所知。正面的例子是 AI 知识库系统用户每编辑一次答案都会让知识库质量更好。第三个问题如果竞品用同样的模型复制你的界面他会不会卡在数据或者流程上他需要多长时间才能补齐你手里的工单记录、设备日志、行业术语表如果他认为三天就能做完那说明产品还很薄。现场感更强的方法是做一个“换脑实验”。把系统里所有直接调用大模型的代码都换成 mock然后观察哪些功能仍然可用哪些功能立刻失效。最后你会发现真正留下来的往往是你自己的业务模块、数据表和审批流程而不是模型本身。2.3 原生应用成熟度可以从四个维度看讨论 AI 原生应用架构成熟度时我一般看四个维度Context 管理、执行控制、知识更新、反馈闭环。Context 管理。低成熟度做法是把所有参考资料都塞进系统提示词不看长度不设优先级结果上下文越来越长模型越来越“健忘”。高成熟度做法是按任务动态检索做摘要、压缩、路由让模型每次只看到它真正需要的信息。执行控制。低成熟度做法是让模型直接调工具失败后不记录也没办法回溯。高成熟度做法是有清晰的权限管控敏感操作需要审批每次执行都有 trace出现问题能定位到具体步骤。知识更新。低成熟度做法是知识一变就改提示词改完也不知道有没有影响其他任务。高成熟度做法是把文档、标准、FAQ 放到知识库里做版本管理和权限控制知识更新后可以通过测试集验证输出。反馈闭环。低成熟度做法是靠用户主动说“这个不对”“那个不好”然后人工调整。高成熟度做法是自动记录用户点击、修改、删除行为把隐式反馈转化为评估指标定期回灌到模型评估和知识更新中。这四个维度如果都停留在低水平无论接的是 GPT 还是国内开源模型做出来的应用在用户眼里都差不多。相反只要执行控制和反馈闭环做得扎实产品就会产生和模型解耦的系统能力。2.4 一个更有说服力的场景行业数据 数字孪生 机器人在机械装备这类行业里“AI 数字孪生 机器人”的落地路线可以很好说明护城河到底在哪。假设你要做一台装备的维修助手。如果只把大模型接上设备说明书做问答那当然很容易被复制。真正能拉开差距的形态是智能体能读取设备的历史巡检记录、故障工单、实时传感器数据回答问题时能调用数字孪生模型圈出具体故障部件需要进一步检查时可以