企业官网建设流程全解析

最近在折腾一个叫 OpenClaw 的个人 AI 助理项目，拆箱、组装、调参数、接工具，一路踩坑一路填坑。这个系列就是想把这台“机器”从头到尾养熟的过程记录下来，既是给自己留个底，也是给同样在折腾这类项目的朋友一个参考。这第一篇先把最基础的东西讲清楚：基础配置、Tool 装配，以及一堆杂七杂八的问题，能避的坑尽量帮你们提前避掉。

先交代一下背景：我手上这个 OpenClaw 实例跑在一台闲置的个人服务器上，模型部分接的是本地推理服务，操作系统是普通的 Linux 发行版，没有用容器，直接裸机跑。之所以这么选，主要是想先把链路摸清楚，排除虚拟化带来的额外变量。如果你是用 Docker 或者其他方式部署，配置思路是一样的，只是路径和环境依赖略有差别。

这篇适合三类人看：一是刚把 OpenClaw 装好、准备开始配置的朋友；二是已经跑起来了但 Tool 调用老出问题、想查缺补漏的；三是对这类 AI 助理项目感兴趣、想了解它内部工作方式的好奇型读者。我尽量把每一步的“为什么”也讲清楚，而不是丢一堆配置片段让你自己猜。

1. 项目整体设计与思路拆解

1.1 为什么选 OpenClaw 这类项目来“养”

OpenClaw 本质上是一个把大模型接进本地环境的“调度中枢”。你可以把它理解成一个管家：你给管家下达指令，管家调动各种工具——查文件、跑命令、调接口、发通知——最后把结果回给你。模型是大脑，OpenClaw 是手脚，工具是手指头。没有这套中枢，你喊破嗓子让模型去读你本机的某个配置文件，它也只能摊手——模型再聪明，它够不到你的磁盘。

我之所以选这类项目而不是直接裸调 API，核心原因是它把“上下文管理”“工具注册”“权限控制”“多轮任务拆解”这些脏活累活都封装好了。你不需要自己维护一套复杂的状态机去追着模型问“你还记不记得刚才说了啥”，也不需要手写一大堆函数调用的胶水代码。这类项目的价值在于：你想让 AI 干活，而不是让 AI 陪你研究怎么干活。

这个系列叫“养虾”，其实是把 OpenClaw 当成一只虾在养——喂料（数据/配置）、换水（清理上下文/日志）、观察状态（看日志/看调用链）。养虾的重心在前期的水质调校和日常的规律喂养，养 OpenClaw 也一样，前期的配置和工具圈定决定了后面好不好用。

1.2 配置思路：先跑通，再调优

我第一次上手的时候犯了一个典型错误：一上来就想把所有功能配齐，各种工具全挂上，模型参数反复横跳，结果哪里都响、哪里都响不明白。后来我把思路强行拉回到一个简单原则——最小可用闭环。

所谓最小可用闭环，就是先把“用户说一句话 → 模型理解 → 调用一个工具 → 返回结果”这条链路彻底跑通。比如你先只给它一个工具：读取系统时间。这个工具足够简单，结果确定性高，链路跑通了你能立刻感知到整体流程是否顺畅。如果这一步就走不通，那问题大概率出在模型接口或者底层通信上，而不是工具太多互相抢资源。

这一步的思考逻辑是：配置系统的复杂度其实不是加法的，是乘法的。你挂 5 个工具，你就要面对 5 个工具的输入输出格式问题、权限问题、解析问题，以及工具之间互相干扰的问题。工具少的时候排查很容易，工具一旦多了，报错信息交叉在一起，就跟线团缠住了似的。先把一个工具跑到零报错，再慢慢加，是这类项目最稳妥的上手方式。

2. 基础配置的关键细节与实操要点

2.1 配置文件结构与核心字段

OpenClaw 的主配置是一个 JSON 文件，位置一般在用户目录下的隐藏配置目录中，名字通常是openclaw.json或config.json。不同版本字段名可能有细微差异，但核心结构大同小异：一个全局配置段、一个模型段、一个工具段、一个权限段。

我拆一下我实际在用的关键字段，方便你对照自己的版本：

• model段：模型服务地址、模型名称、上下文窗口长度、温度等。如果你接的是本地推理服务，地址一般是http://127.0.0.1:11434这类；如果接的是云端 API，就是对应的接口地址和密钥。
• tools段：一个数组，每个元素是一个工具声明，包含工具名称、描述、可调用参数、是否默认启用。
• system_prompt段：给模型的系统提示词，相当于给管家交代工作守则。
• working_dir段：OpenClaw 执行本地命令时的工作目录，隔离作用大于方便作用。
• permission段：工具调用的确认策略，分为三种常见的——全部静默放行、需要手动确认、按工具逐一指定。

强烈建议你在改配置前先备份原文件。我吃过一次亏，改坏了一个字段，整个服务起不来，日志里只显示一行通用的 JSON 解析错误，排查的时候看哪里都像对的，最后发现是漏打了一个逗号。这种低级错误用备份恢复最快。

2.2 模型选择与服务地址配置

模型这块是 OpenClaw 的地基，地基歪了上面全白搭。我试过几种路径，说下实际感受：

用云 API 的好处是省心，上下文窗口大、响应快、对复杂指令的理解能力强。缺点是每条 Tool 调用都会有延迟，而且 Token 消耗会随着工具调用链变长而快速上涨。比如你让它“查一下某个目录下最新的那个文件的内容并把摘要发给我”，这一条指令背后可能是三次或者更多轮内部调用，每一轮都要消耗一定量 Token，加在一起就不便宜了。

用本地模型的好处是免费、隐私好、无限调用也不心疼。缺点是性能受硬件制约，小参数模型在理解复杂指令、正确拼装工具参数方面会弱一些。我用中等体积的量化模型跑日常任务，结果基本可接受，但一旦指令有歧义，它偶尔会把工具参数拼错。这就是典型的“模型理解偏差导致工具调用失败”，属于这类项目里最常见的问题之一。

我的建议是：如果你只是尝鲜、跑测试，本地模型完全够用；如果你要在生产环境里跑自动化流程，云 API 的稳定性值得多花点钱。当然也有“混合路由”的做法——简单任务走本地模型，复杂任务走云 API，这个后面有机会可以展开说。配置上，模型段基本是即改即生效的，前提是 OpenClaw 支持热加载；如果不支持，改完就得重启主进程。

3. Tool 装配全流程与核心环节实现

3.1 Tool 声明里的信息差

Tool 是 OpenClaw 的核心资产，它的装配机制和插件系统类似。我先说一个重要概念：在给大模型定义工具时，描述信息比参数格式更重要。

你定义一个工具给模型看，模型没见过这个工具的实际代码，它只能靠工具名和描述来理解“这个工具是干嘛的、什么时候该用它、参数怎么填”。如果描述写得太抽象，模型就不确定该不该用；写得太啰嗦，模型可能会被无关信息干扰，反而抓不住重点。我自己踩过的坑是：把工具的 JSON 描述写得很详细，结果模型频繁误用——它不是根据语义去匹配，而是机械地按字面去触发，最后调用出来的参数一塌糊涂。后来精简了描述，用一两句话讲清用途和触发场景，误调率明显下降。

工具描述最好包含三个要素：干什么的（用途一句话）、什么时候用（触发条件）、参数怎么填（格式提示）。这三个要素越具体，模型的理解成本越低。调整后的描述比如“在指定目录内查找文件名匹配给定模式的文件列表，当用户想找某个文件但不确定确切名字时使用”，这样的描述比光写一个“find_files”要可靠得多。

3.2 参数定义与类型校验

工具参数的定义格式用的是 JSON Schema 风格，支持字符串、整数、布尔、数组、对象等类型。每一项参数都可以设置是否必填、默认值、枚举值范围等约束。这在 OpenClaw 里会拿参数约束去校验模型的输出，不合法就重试或者直接报错。

我实际用的时候有一个体会：不要过分约束参数范围，但要严格约束参数类型。类型错了模型不会魔法修复，直接导致调用失败；而范围约束如果收得太紧，模型可能找不着可选项就胡乱填。举个例子，你定义一个“查询服务器状态”的工具，参数是服务器名称。你给一个枚举列表，列出三台机器，模型基本不会犯错；但如果你定义的是一个“运行任意命令”的工具，还允许传 shell 命令，那权限风险就完全暴露了——这种情况一定要设置成手动确认，或者干脆默认禁用。

在参数安全方面我给自己立了一条规矩——凡是涉及文件增删、命令执行、外部请求这三类工具，全部设为“调用前确认”。虽然多了一步人工点头，但换来的是不会被一次上下文污染带偏然后做出不可逆操作。OpenClaw 的权限控制如果配置得当，能够极大降低这类系统的翻车概率。

3.3 三批工具的接通顺序

我实际挂载工具时分了三个批次，每批之间间隔一天，目的就是观察它在真实任务里的表现，避免工具之间互相干扰。第一批是一组基础工具：查时间、读文件、列目录、搜索文本。这组工具全部是只读的，不会造成破坏，适合用来验证链路。

第二批加上了“写文件”和“执行 shell 命令”。这两个工具属于双刃剑——方便是真方便，风险也是真风险。我给写文件设了默认路径白名单，只允许在指定目录下创建和修改；shell 命令则全部走手动确认。如果你打算让模型处理你工作目录里的日常事务，这个白名单思路值得借鉴，别让它拿根目录权限满世界乱跑。

第三批是外部接口类的工具：调用 HTTP API、发消息通知等。这批工具涉及网络交互，最需要注意的是超时设置和返回体大小限制。我试过模型调用一个外部接口，对方响应很慢，OpenClaw 等了很久也不返回，整个会话像是卡死了。后来给这类工具统一加了连接超时和读取超时的配置，超时就立即报错返回，不影响后续对话继续。

4. 实操记录：从零把第一个工具跑通

4.1 最小工具的完整定义

为了让你有一个可以照着抄的起点，我把“读取系统时间”这个最小工具的实际配置写出来，这是我验证链路用的第一个工具。在 OpenClaw 的配置中，它长这样：

{ "name": "get_system_time", "description": "获取当前系统日期和时间。当用户询问现在几点或当前日期时使用。", "parameters": { "type": "object", "properties": {}, "required": [] }, "enabled": true, "permission": "auto" }

这个工具不需要任何入参，所以 parameters 是空对象。permission 设为 auto，意思是模型可以静默调用，不需要我手动确认。对于一个无害的读取操作来说，这个权限强度是合理的。

定义完工具之后，我重启了主进程让配置载入，然后在对话框里输入“现在几点了”，OpenClaw 返回了时间，并且附带了调用工具的记录。第一次看到模型自己把工具调用参数拼装好、把结果送回对话里的时候，那种感觉就像是虾第一次脱壳成功——环节很小，但它意味着整个机制转起来了。

4.2 从配置到调用的完整链路检查

如果这个最简单的工具都没跑通，排查方向按优先级来：第一查模型地址是不是通；第二查系统提示词里有没有阻止工具调用的内容；第三查工具定义格式是否合法。我举个例子说明一个隐蔽的坑：系统提示词里如果写了一句“仅基于你的知识回答用户问题”，模型就会倾向于纯文本应答，完全不会去调用工具——也就是说，你在系统提示词里限制了模型的调用习惯，它就会乖乖听着，哪怕有工具可用也不碰。这个问题我当时排查了很久，因为工具配置完全正常，但模型就是不碰工具，最后罪魁祸首是一句话语气很强的提示词。查这类问题最快的方法是把系统提示词临时置空再试一次，如果工具开始触发了，那问题就在提示词上面。

我推荐一个排查方法：打开 OpenClaw 的详细日志，观察每次用户请求进去之后，系统有没有生成工具调用的内部指令。如果没有生成，说明问题出在模型理解层；如果生成了但调用失败，那问题出在工具执行层。这个分界可以帮助你把排查范围缩小一半以上。

4.3 工具调用链路上的性能观察

工具调用不是白给的，每次调用都有开销。当你给模型装上工具之后，就算你只是随便问一句“你好”，它内部也可能在评估工具列表，只是最终没触发而已。随着工具数量增加，这个评估动作的耗时也在上升。我用一个简单方法测了一下：同样的一个问题，在只有 5 个工具的时候和 15 个工具的时候，响应时间差距比较明显。这不是网络波动，而是模型每次都要把工具描述过一遍。

所以我给工具做减法的原则是：不常用的工具不放进工具列表，改用临时加载的方式。OpenClaw 支持按需加载工具，也就是在某些特定任务里才挂载对应工具，日常不占用列表空间。这样一来，模型每次评估的负担小很多，响应也流畅了。如果你发现配了一堆工具之后 OpenClaw 变“笨”了或者变“慢”了，大概率就是这个原因。

5. 问题排查与避坑实录

5.1 高频问题速查表

这部分是我整理了这段时间遇到的高频报错和对应的解决办法，做成一个速查表，遇到问题时可以先对照一下再动手。

表格里每一列都值得展开说，但这里最想强调的是“描述模糊”和“描述重叠”这两个问题。前者让模型不知道什么时候该用，后者让模型分不清该用哪个。我的解决办法是给每个工具加一句“仅当……时才使用”，把触发条件的边界划清楚。

5.2 日志里的信息筛选方法

OpenClaw 的日志详细度是分级的，默认级别下只能看到请求来了、走了，中间细节全被吞了。排查问题第一步就是把日志级别调到最详细，具体配置因版本而异，一般是debug级别。这个级别下会记录模型返回的原始内容、工具调用的指令片段、每一步的时间戳。信息多了之后的毛病是太吵，每一轮对话刷出大量记录。

我的经验是：先跑一个最小复现问题，然后立刻把日志导出，再根据关键词“tool_call”或“function_call”来过滤出与工具调用相关的行。在这个过滤结果里，你基本能看到模型生成的工具名称和参数草稿，以及执行后返回的结果。大多数工具相关问题都藏在这几行里。

日志还有一个隐蔽用途——观察时间消耗。如果你发现某一次调用耗时特别长，多半是工具执行时做了预料之外的事情，比如某个命令递归扫描了整个目录。这种情况比直接报错更值得警惕，因为它不会失败，只是空转浪费资源。

5.3 几件常规文档里不会写的事

第一件事是工具执行环境与主进程环境的差异。OpenClaw 主进程可能跑在一个干净的 shell 环境里，但你本机的 PATH 和用户目录下的工具链可能没有完整继承。我遇到过模型调用ffmpeg提示找不到命令，但在终端里手动敲是正常的——原因就是 OpenClaw 的子进程环境没有加载你 shell 配置文件里的路径设置。解决办法是在工具的 shell 命令前显式带全路径，或者把常用路径放到 OpenClaw 的环境变量配置里。

第二件事是工具里的“富信息”陷阱。某些工具返回的内容非常长，比如读一个上千行的日志文件再回传，模型处理起来既消耗 Token 又容易丢失重点。正确的思路是：工具只返回“加工过的信息”，而不是“原始的海量信息”。比如读日志文件之前，先在工具里做一次 grep，只返回匹配行的有限片段。这个思路说来简单，但在实际装配过程中太容易忽略了——工具写得省事，后面跑起来就要一直给模型“擦屁股”。

第三件事是重启不等于重新加载一切。我一开始以为改了工具配置，重启主进程就完事了。后来发现某些运行状态下缓存的上下文片段会被保留，新配置跟旧缓存冲突时，表现很奇怪——比如新工具已经启用了，但模型还是按旧的工具列表思考。这时候不要反复重启，干脆把缓存目录清一遍，再用一条简单的测试指令验证。缓存问题虽然不常见，但一旦遇到，单纯重启解决不了。

6. 写在最后的个人体会

这套配置折腾下来，我最大的体会有两个：一是这类 AI 助理项目的瓶颈通常不在模型能力，而在工具描述和权限控制的精细度——模型再聪明，工具没定义清楚它也发挥不出来；二是“少即是多”在这类项目里真是金句，少挂几个工具，多打磨每个工具的细节，整体效果反而更好。

“养虾”系列的第一篇到这里就差不多收尾了。下次我打算聊聊实际用 OpenClaw 跑自动化任务时怎么设计多步骤流程，以及怎么处理那些“模型理解对了但执行结果还是不对”的顽固问题。养虾这件事急不得，基础水位调好了，后面才好养。