如何打造更可靠的龙虾

很多新手在使用 OpenClaw（龙虾）时，倾向于把所有的指令、所有的技能（skills）和所有的上下文都塞给一个主 Agent，试图打造一个“全知全能”的超级助手。这往往会导致大模型“分心”、抓错重点，甚至产生严重的“幻觉”。

真正的工程化思路，是摒弃“单体全能”的幻想，通过合理的架构设计，打造一个稳定、高效、可靠的“龙虾工作流”。

下面我们将从三个技术层次来剖析如何实现这一目标。

零层思考：从 DeepSeek 的爆火看“向量空间分区”

在讲具体做法前，我们需要先理解底层逻辑。近年来 DeepSeek 为什么能爆火，并以极高的性价比展现出强大的推理能力？

其核心之一就是**混合专家模型（MoE，Mixture of Experts）**架构。实际上，早期的 AI 探索者（例如某些基于专家系统的架构）就证明了：不要试图用一个全连接的巨大网络去处理所有问题。目前的顶尖 LLM 都在学习如何对“向量空间进行分区”：

如果连世界顶级的 AI 大厂都在使用“专家分工（MoE）”和“向量空间隔离”来提升性能和准确度，作为普通开发者的我们，凭什么认为在一个 Prompt（提示词）里塞下所有上下文和工具，就能打造出一个“全能龙虾”呢？

顺应 LLM 的底层物理规律，缩小关注点、隔离上下文，才是我们使用 Agent 的第一准则。

如果不遵循这一准则，执意把所有规则和技能堆在一起，大模型就会面临两个致命问题：

幻觉（Hallucination）：当上下文过长、概念过多时，大模型会在其庞大的向量空间中发生“交叉污染”。比如它可能会用前端的框架去写后端的逻辑，或者在不该调用数据库的时候强行“捏造”一个 SQL 查询。
漂移（Drift）：随着多轮对话的进行，由于初期加载的无用信息太多，大模型的“注意力”会逐渐从你当前的核心任务上偏移。聊到第十轮时，它可能已经完全忘记了第一轮定下的严格规范，开始信马由缰。

不要在主 AGENTS.md 中一次性写完所有的细枝末节和长篇大论。大模型的能力虽然强大，但上下文窗口的“信噪比”和“Token 消耗”是真实存在的物理限制。

你应该采用**“渐进式披露（Progressive Disclosure）”**的策略。在顶层的 AGENTS.md 中，只描述：

让大模型在真正执行到特定环节时，再去读取更具体的子文档（如具体的业务规则、API 文档）。这能始终保持主提示词的精简和高效，让它始终清楚“自己当下最重要的任务是什么”。

把所有的 skill 都绑定给一个 Agent，或者一次性加载所有的工具描述，会导致上下文极度膨胀。一次性给太多无用的上下文不仅会让响应变慢，更可能让大模型在众多工具中选错，导致执行错误的逻辑。

通过目录结构和按需加载的方式实现 skill 的渐进式披露。例如，在技能文档的 Frontmatter 中设置合理的 read_when（双语触发词）：

---
read_when: ["需要查询数据库", "query database", "SQL"]
---

让它在恰当的时机（触发了特定关键词或意图时）才去读取和加载对应的技能。这样可以有效缩小 Agent 的体积（缩短 Prompt 长度），显著提高响应速度和指令执行的精准度。

真正的高级玩法是多 Agent 架构。不要试图通过一个超级龙虾来实现所有功能，而是打造一个“团队”。

每个 Agent 都应该有自己独立的 workspace，专注于自己特定的 skills 和领域规则。例如你可以这样拆分：

让它们各司其职、相互协作，将复杂的任务流水线化。把大任务拆解为小巧、职责单一的 Agent 和技能，这才是驾驭 OpenClaw 走向工业级可靠性的正确姿势。