企业官网建设流程全解析

如果把九月初关于 AI 的几个热点放在一起看，会发现一个相当清晰的信号。OpenClaw 2.0 开始谈协作，AI 应用圈开始认真讨论护城河，ClickHouse 这类数据库也开始在智能体基础设施里被反复提起。表面上看，这三件事互不相干：一个是本地智能体运行框架，一个是产品战略话题，一个是基础设施工具。但如果拉远一点看，它们其实在共同回答一个底层问题：当智能体真的进入工作流之后，靠什么让它稳定、可控、持续产生价值？

我的判断是，靠的已经不是某个大模型的生成能力，而是协作规范、执行权限、运行日志和数据分析这一整套工程能力。模型可以换、Prompt 可以抄，但一个智能体能不能在真实环境里被信任，取决于有没有把“能聊”变成“能干活”，并且把每一次干活的过程记录成可复盘的数据。OpenClaw 2.0 的协作、AI 应用的护城河、ClickHouse 的智能体基础设施，其实是同一件事的三个切面。

1. OpenClaw 2.0 的“协作”，不是聊天，而是把执行边界管起来

OpenClaw 之所以能在本地智能体项目里受到关注，不是因为它能把对话做得更丝滑，而是因为它尝试回答一个很麻烦的问题：当一个智能体不只是一个聊天框，而是一个会读取文件、调用工具、执行命令、操作系统资源的程序时，怎么让它在自主性和可控性之间找到可落地的平衡。

很多人会把“协作”理解成“多个机器人在一起开会”，但本地智能体框架里的协作远不止这一层。OpenClaw 2.0 更值得关注的，是把智能体、工具、用户审批、工作区、技能这几个对象组合成一条可执行的链路。这个设计背后有一个明确目的：智能体要做的事越接近真实操作，它的运行边界就需要越清晰。

1.1 先从安装和模型配置说起：本地智能体为什么容易卡在第一步

很多第一次接触 OpenClaw 的人，会误以为安装 agent 框架和装普通软件一样，下载后一路下一步就行。实际体验远没有这么简单。常见安装方式会根据操作系统不同而变化：Windows 上很多人用 PowerShell 安装，Linux 上则习惯用脚本或包管理工具。无论哪种方式，安装都只是起点，后面还有工作区初始化、模型接入、技能配置和权限审批。

我见过很多安装后跑不起来的案例，最后看日志往往不是安装失败，而是模型配置没到位。比如框架默认配置里写了一个模型标识，但你想改成本地模型或国内服务商的模型时，没有把名字改成服务端真正支持的模型 ID。这种情况下，启动对话后就会报类似 “unknown model: deepseek-...” 的错误。一堆人搜“openclaw unknown model”，其实问题不是框架坏了，而是模型名和接口地址没对上。

处理顺序可以这样走：

1. 先看配置文件里的模型列表或示例，确认框架支持哪些模型来源。
2. 再看你填的模型名是不是服务端文档里的“模型 ID”，不是模型展示名称。
3. 检查 API 地址是否正确，有些本地推理服务需要带/v1路径。
4. 确认 API Key 环境变量已经加载，而不是只写进了 shell 但没有 export。
5. 最后用最简单的模型参数跑一条请求，绕开所有技能和工具，先验证“基础对话”。

这个流程看起来琐碎，但它决定了后面的所有操作是否可信。模型配置没弄好，后面加再多 skill 都是空中楼阁。

1.2 skill、workspace、exec-approvals：把“能聊”升级成“能干活”

我在跟踪 OpenClaw 相关热词时，发现“openclaw skill”“openclaw workspace”“openclaw 部署”这些词的搜索频率很高。这说明多数使用者已经不只是想让智能体聊天，而是想让它完成具体任务。

skill 在智能体框架里的作用，可以理解成“预置的操作说明书”。它不只是给模型一段 Prompt，而是描述某个任务什么时候该触发、需要调用什么工具、中间要注意什么边界。通过把技能拆成可复用的模块，智能体面对开放式任务时才不会每次都从零开始“猜”流程。

workspace 则是给智能体划出的工作目录。通常会在用户主目录下生成类似~/.openclaw/workspace的路径。所有需要落盘的文件、中间产物、外部输入都可以被限制在这个目录里，避免智能体在系统任意路径上读写。这个设计在本地智能体里极其重要，因为一旦允许 agent 执行代码或操作文件，它就有了真实的系统副作用。

另外一类常见提示，是热词里反复出现的 “legacy exec approvals exist at /root/.openclaw/exec-approvals.json”。这个信息看起来像报错，其实更像一次安全提醒。它告诉你：旧版本里，用户对某些命令的“审批允许记录”还留在文件中。版本升级后，框架不能确认这些历史允许规则是否仍然可靠，于是会停下来要求处理。

我第一次遇到类似问题时的反应是直接删掉旧文件，后来发现更好的做法是：先备份，再打开文件看内容。如果里面只是一些无害的查询命令，可以把它们迁移到新版本的授权配置里；如果里面有allow all这种全量放行规则，那就不能保留。核心原则是：不要让 AI 来决定自己能不能执行高风险的命令，这个决定权必须保留给人和明确配置。

1.3 接微信之前，先想清楚审批策略

关于 OpenClaw 接入微信的讨论很多。从技术上看，本地智能体接入 IM 工具并不困难，无非是把消息平台的事件转发给 agent，再把回复发回去。真正需要谨慎的不是“能不能接入”，而是“接入之后到底赋予它多大权限”。

如果只是让 agent 在 IM 里帮你做摘要、查资料、回答知识库问题，风险还能接受。但如果让它读你的聊天记录、读取邮件、发送文件、甚至执行代码，那就要先回答几个问题：

• 谁来批准高危操作？
• 在什么时间段内允许它自主执行？
• 如果它被一条恶意构造的消息诱导执行命令，是否有预案？
• 工作目录和审批记录是否在隔离环境里？

我建议把聊天工具的接入分成两个阶段。第一阶段只做“读消息、回复文本、调用无副作用的搜索/知识库工具”；第二阶段才逐步开放文件操作和执行命令。并且在开放之前，先想清楚权限边界，而不是在群里对着真实账号测试。

协作的意义不是让智能体大包大揽，而是让它在合适的节点把控制权交还给人类。OpenClaw 2.0 这类的“协作升级”，本质上是在设定这种交接规则。

2. AI 应用的护城河，从来不是“我接入了最强大的模型”

和 OpenClaw 这类框架的热度同时出现的，是另一个老话题：AI 应用的护城河到底在哪里？过去一年，很多人搭一个套壳应用，接入大模型 API，然后发现用户增长来得快、流失也快。原因很简单：当产品核心只是把 Prompt 和 API 包一层壳，它就很难形成长期壁垒。

但这不是说 AI 应用没有护城河，而是说护城河不在大多数人以为的位置。

2.1 模型能力可以被替换，流程和数据不会

如果你的应用只是把用户输入转发给一个强大的外部模型，再把模型输出原样返回，那么任何一个新入局者都可以用同样的方法实现。模型选择、上下文长度、生成速度，这些能力在今天已经越来越同质化，而且更新换代极快。

真正让用户留下来的是另外一些东西：

• 用户在你的产品里留下的历史记录和偏好，能不能形成个性化的记忆。
• 用户通过反复使用形成的自动化工作流，迁移成本高不高。
• 针对特定行业的术语、规则、案例，是否已经沉淀成知识库和评估集。
• 产品的输出质量是否能被持续度量、修正和验证。

这些资产全部来自应用层，而不是底层模型。你可以换一个更强的模型，但用户积累下来的数据不会自动迁移。你可以优化 Prompt，但别人也可以抄走你的 Prompt。真正难复制的是“数据飞轮”：每次使用产生数据，数据又反过来改善下一次输出和服务质量。

所以，如果把“接入了最强模型”当成护城河，那这个护城河几乎不存在。反过来，如果把“每一轮运行都变成可量化的数据资产”当成目标，那护城河会随着使用时间越来越宽。

2.2 护城河数据从哪里来？从每一轮运行里捞

很多团队不是不知道数据重要，而是根本没把数据留下来。他们在演示智能体时只会截图聊天记录，却没有记录系统运行时的结构化信息：模型调用消耗了多少 token、工具调用是否成功、用户在哪一步放弃了任务、哪一个指令导致 agent 反复重试。

这些信息才是 AI 应用后续迭代的原材料。没有它们，你只能靠人工抽样去猜产品哪里有问题，无法知道真实的失败率，也很难建立自动化回归体系。更现实的是，没有这些数据，你没法回答投资人或者老板最常问的三个问题：

• 这个智能体每月实际带来了多少收益？
• 它最常被用来完成哪几类任务？
• 失败最多、成本最高的场景是哪些？

要回答这些问题，就必须在每个智能体事件发生的时候，把关键字段记录下来，然后放到一个能支撑查询分析的地方。这正是 ClickHouse 这类基础设施会出现在智能体技术栈里的原因。

2.3 不是所有产品都需要护城河：先判断阶段

这里要补一个边界：不是所有 AI 应用都急着挖护城河。如果只是个人工具、课程 Demo、内部效率工具，或者还在验证需求的早期阶段，都谈不上“护城河”三个字。这时候最应该做的是快速验证价值，用最笨的方式把流程跑通。

我会先问自己一个问题：如果明天模型厂商把价格降到零，我的产品还能不能存在？

如果答案是“能，因为用户已经习惯了我们独特的工作流和记忆系统”，那就值得提前搭建运行数据基础设施。如果答案是“不能，因为用户就是冲着模型本身来的”，那就说明产品离真实价值还有距离。与其先上 ClickHouse 这类重型基础设施，不如先把交互体验做透，看用户是否愿意反复使用。

护城河不是规划出来的，而是通过一轮轮使用数据慢慢长出来的。早期最重要的事情是找到“高频、高价值、可重复”的任务场景。

3. ClickHouse 在智能体基础设施里，到底解决什么问题

当智能体开始被用于真实业务时，运行数据就不再是可有可无的日志，而是一种必须被结构化管理的基础设施。于是 ClickHouse 这种原本偏数据分析场景的列式数据库，开始进入智能体应用的技术选型。

它解决的问题不是“怎么把一个聊天记录存下来”，而是“怎么让每一次智能体运行都能被低成本地记录、聚合、回溯和评估”。这背后是智能体应用从 Demo 走向生产环境时的必然需求。

3.1 智能体会产生什么样的运行数据

假设你有一个稍微复杂一点的智能体：它接收用户请求，调用知识库检索，再调用一个工具去查业务系统，最后生成回复。在这一轮任务中，至少会产生以下数据点：

• 会话 ID 和用户 ID，用来串联整个任务过程。
• 事件类型，比如用户输入、模型生成、工具调用、上下文更新。
• 模型名称、输入 token 数、输出 token 数、推理延迟。
• 工具名称、工具入参摘要、工具返回值状态、失败原因。
• 整体任务是否成功，以及用户在完成后是否对结果做了反馈。
• 时间戳，以及可能的环境/版本标签。

这类数据的特点是：单条数据量不大，但产生频率高、增长快，而且需要按时间去聚合分析。如果你一天跑几万次智能体任务，一次任务产生几十条事件，光靠人翻日志是不现实的。

用普通关系型数据库也可以存，但当数据量到达千万级以上，并且需要频繁执行“某一天内某工具失败率”“平均每次任务消耗多少 token”这类汇总查询时，列式存储的优势就会显现出来。

3.2 为什么列式数据库更适合这种场景

可以把 ClickHouse 理解成一个“专门为大量数据写入和高性能聚合分析设计”的数据库。它不是用来替代业务系统的在线事务库，而是承担类似“运行数据仓库”的角色。

这个差异在智能体场景里很重要。因为智能体事件一旦写入，几乎不需要单独更新某一条记录。你更多是想回答“昨天凌晨那批任务的失败率是多少”“哪个模型输出 token 数最高”这类聚合问题。ClickHouse 在这类查询上的性能通常远超普通数据库。

3.3 一张最小 agent_events 表，一开始就应按“可分析”设计

很多团队一开始只把智能体日志打印到控制台，觉得以后要分析了再处理。等到真的想做分析时，发现日志格式不统一，字段缺失，无法回溯。与其这样，不如从第一版就开始定义一张尽量轻但结构完整的事件表。

下面是一个常见方向的结构示例，具体字段可以按你的业务调整。

CREATE TABLE agent_events ( event_id UUID DEFAULT generateUUIDv4(), agent_name String, session_id String, event_type String, tool_name String, model_name String, prompt_tokens UInt64, completion_tokens UInt64, latency_ms UInt64, success Bool, error_msg String, event_time DateTime DEFAULT now() ) ENGINE = MergeTree() PARTITION BY toYYYYMMDD(event_time) ORDER BY (agent_name, event_time);

这张表没有刻意追求精细，而是先保证几件事：

• 每次事件都有独立 ID，方便和原始日志关联。
• 有 agent_name 和 session_id，可以区分任务和会话。
• 有 token 和耗时字段，用来算成本和性能。
• 有 success 和 error_msg，用来定位失败。
• 按天分区，方便做每日清理和归档。

写入时不要只传事件消息，尽量把 agent_name、model_name、latency_ms 这类结构化字段都填上。只有结构化的数据才能在未来支撑自动化的监控大盘。如果你现在只在日志里写了一句 “agent 执行成功”，那以后做分析时会非常痛苦。

3.4 集群模式最容易踩的认证坑

ClickHouse 本身部署并不复杂。用 Docker 起一个单节点，通常只需要映射 HTTP 端口和 native 端口，再挂一个数据目录。不少团队为了日志量能扩展，会直接上集群模式。这时很容易踩到一个经典报错：

user: default: authentication failed: code: 193.

这个报错在单节点环境也可能出现，但集群模式下发生的概率更高。原因是 ClickHouse 在集群配置里涉及多个节点之间的分布式表访问，需要节点之间用账号密码互相通信。如果集群配置里写了一个密码，而实际节点的 user.xml 里没有同步更新，或者客户端连接时使用了错误的密码，就会出现认证失败。

遇到这个问题不要先怀疑代码，按下面的顺序排查：

1. 先确认是客户端连单节点失败，还是集群内部节点互相访问失败。
2. 在单节点上用你用来连接的那个账号密码，直接执行一条简单查询，确认本地认证没有配置错误。
3. 检查几个节点的 users 配置是否一致，特别是用 Docker 挂载配置文件时，很容易出现某个节点沿用旧配置。
4. 检查集群配置里的 shard 和 replica 地址有没有写错，是否用容器 IP 或主机名混淆了网络连接。
5. 查看 ClickHouse server 日志中的认证来源，判断是哪一端发起了访问。

这里最容易忽略的是一个细节：default 用户在默认情况下可能不需要密码，但一旦你在某个节点上给 default 配置了密码，就要同步到所有需要跨节点访问的客户端和服务端配置里。很多人只改了数据节点，忘了改分布式表连接的配置，于是便看到 193 报错。

4. 从 OpenClaw 到 ClickHouse：我把智能体工程化分成四个阶段

如果只讲 OpenClaw，容易让读者误以为装一个本地框架就够了。如果只讲 ClickHouse，又容易忽略它到底服务于什么。所以我想把文章里三条线索放在一张图里，给一个可复用的阶段框架。无论你用的是 OpenClaw、其他智能体框架，还是自研 agent，都可以用这个路径来检查自己走到了哪一步。

4.1 阶段一和阶段二：从能跑到能协作

阶段一是“能跑”。智能体可以在本地启动，完成基础对话，并且已经接入至少一个模型。这个阶段最重要的衡量标准不是功能多，而是链路要通：模型请求能发出、回复能返回、日志能记录。

阶段二是“能协作”。这个协作包括三个部分：智能体能否调用外部工具；能否在需要执行高危操作时把审批交给用户；能否通过 skill 或类似机制把常用任务固化成可复用流程。OpenClaw 2.0 的“协作”，本质上就在解决这个阶段的问题。

很多项目死在从阶段一到阶段二的路上，不是因为模型不够聪明，而是因为没有设计好工具调用边界。智能体一旦可以调用工具，就有可能出现“连不上数据库、API Key 暴露、执行了不可逆操作”等问题。所以阶段二的关键词是权限、审批和隔离。

在落地时，我建议按这条顺序验证：

1. 先让智能体调用一个无副作用的工具，比如天气查询或知识库检索。
2. 检查它是否能正确读取工具返回结果。
3. 加入写文件或执行命令前的人工审批。
4. 在隔离目录里测试所有可能的高危操作。
5. 最后再把任务暴露给真实用户或 IM 群。

4.2 阶段三和阶段四：从可观测到可持续积累

阶段三是“可观测”。它要求你能够回答：这个智能体每天跑了多少任务、成本多少、成功率多少、哪个工具最常失败。能回答这些问题，前提是数据结构化落库，并且在仪表盘上能直观看到。

这时 ClickHouse 就派上用场了。你可以把 agent_events 这类表中的数据消费成日常指标。比如按小时统计 token 消耗趋势，按 agent_name 分组统计失败率，按 tool_name 统计工具调用量。这些指标能让你在智能体出现劣化趋势前就发现异常，而不是等用户投诉后再去翻日志。

阶段四是“可持续积累”。这也是护城河开始出现的时候。你已经有了一套评估集，知道哪些任务需要重点回归；你积累了用户反馈，开始用这些反馈微调 Prompt 或工作流；你还能根据成本和成功率决定，哪些任务交给更强更贵的模型，哪些任务用便宜模型处理。这个阶段的价值不是某一次运行表现好，而是每一次运行都在帮助系统变得更好。

4.3 一个“先跑小闭环”的检查清单

总结成一个可复用清单，适合团队从一个简单智能体开始，逐步走向工程化：

• 确认你已经能输出结构化日志，而不是只有 stdout 文本。
• 确认每条日志都能关联到 session_id 和 agent_name。
• 确认工具调用有耗时、成功与否、错误信息等关键字段。
• 确认模型 token、成本和延迟有记录。
• 确认高危操作有审批或白名单规则。
• 确认异常情况可以被监控报警，而不是只能事后排查。
• 确认从数据落库到分析看板的路径是自动化的。

每过一道检查，智能体离“真实生产环境”就更近一步。

5. 适用边界：这类智能体基础设施不是人人都需要

上面讲了一整套从 OpenClaw 到 ClickHouse 的工程化思路，但我并不认为所有做智能体的人都需要立刻照做。过度设计在这个领域同样存在。理清边界比堆技术栈更重要。

5.1 什么时候不要上 ClickHouse

如果智能体只是个人玩具、内部小范围试用，每天调用量只有几百次，用 SQLite 或 PostgreSQL 存数据也完全够。此时引入 ClickHouse 会增加部署成本和运维负担，并不能带来实际收益。

另一个“不要上”的情况，是你的业务还没有明确分析需求。如果你根本不知道拿到这些统计数据后要做什么决策，那先别急着做复杂数仓。更好的方式是先把结构化日志存到简单数据库，积攒到一定量后再考虑迁移到 ClickHouse。

如果你确实需要跨天、跨用户、跨工具做分析，并且现有数据库在查询时明显变慢，再引入 ClickHouse 会更合适。记住，它负责的是分析和监控，不是你的业务主存储。

5.2 什么时候不要过度强调 Agent 协作

同样地，不是所有任务都需要让智能体去执行命令或调用一堆工具。很多场景只需要一个优秀的文本生成接口；强行加协作只会增加延迟和不确定性。如果一个任务用传统规则或普通搜索就能解决，就没有必要让智能体承担决策风险。

“协作”真正有价值的场景，是任务需要多步拆解、多次查询外部系统、并且需要综合多个结果才能产出答案。如果任务本身只有一次模型调用，那就不应该叫 agent，更谈不上基础设施。

我在判断是否给一个场景引入智能体框架时，会先看两个条件：

• 这个任务是否天然包含分支判断。
• 这个任务是否必须访问动态外部信息。

二者至少满足一个，才值得进入 agent 化流程。否则，用普通函数调用或固定 Prompt 可能更稳定。

5.3 真正的竞争力来自使用中长出来的数据

回到文章开头的问题：当智能体进入工作流之后，靠什么让它稳定、可控、持续产生价值？我的答案不是某一个具体框架或数据库，而是三条基本纪律：

第一，让智能体的每一次运行都有边界。OpenClaw 2.0 里的审批、workspace、skill 设计，本质上都在做这件事。

第二，让每一次运行都可被观测。ClickHouse 这类基础设施解决的不是“存日志”，而是把一个模糊的“AI 能力”变成一组可以衡量、可以优化的业务指标。

第三，让每一次运行都成为下一次运行的养料。只有当数据被持续分析并反哺到产品里，护城河才开始出现。

所以，09-01 这几个热点真正值得记下来的，不是“又有一个新框架”或“又有一个数据库参与讨论”，而是同一个工程命题的不同表达：智能体要从“会聊天的演示品”变成“能稳定交付的生产工具”，最终拼的是执行边界、数据闭环和持续迭代能力。如果你刚开始做智能体，下一步最该做的不是急着接更多 IM 或引入更强模型，而是先把一个最小任务完整跑通，然后把这次跑通的过程变成第一份结构化日志。