做企业级AI Agent的时候，几乎每个人都会踩同一个坑。

Demo阶段，所有人关心的都是效果——”能不能跑通？””回答准不准？””看起来聪不聪明？”没人盯成本。

等到系统真正跑起来，账单甩到你脸上的时候，你才会感受到——

Token 就是 Agent 时代的电费。而说到省 token，大部分人上来就盯着 prompt 写短点、加个缓存——这些当然有用，但它属于末端的小修小补。真正的省，在架构和治理决策的关口上。

我给你拆成四个层级，从前到后，越靠前越剩的多。

第一层：权衡适用于Agent的场景

这是最容易被跳过的一层，也是最省钱的一层。

现在 Agent 太火了，火到什么程度呢？很多团队一上来就把所有任务都包成 Agent。但 Agent 的本质是什么？是”让大模型自己决定下一步做什么”。大模型每一次生成都带着概率和随机性——这既是它智能的来源，也是它成本和不确定性的来源。

所以判断标准其实特别朴素——

流程固定的，用 Workflow。路径不确定的，才用 Agent。

什么叫流程固定？简单说就是你能提前把它画成一张流程图。

工单分类路由、固定格式的信息抽取、按模板生成回执、定时报表汇总——这些事儿步骤是确定的，不需要让模型思考。该调模型的环节调一次就行了，其余靠规则流转。

这一刀砍下去，token 消耗可能直接腰斩。而且结果更稳定、更可控——LLM的本质还是概率预测，这样也可以减少模型突然”灵光一现”走偏了的情况。

那什么场景必须上 Agent 呢？事先画不出完整流程图、下一步依赖上一步结果的那种开放式任务。比如做一个调研——下一步搜什么、要不要深挖，取决于上一步查到了什么。比如一个故障排查——先看日志，然后根据日志内容决定是查数据库还是查配置文件。

这种”走一步看一步”的活儿，才值得为 Agent 的灵活性付那个溢价。

一个很容易踩的坑：Agent 拆太碎了

就算你确定了某个场景该上 Agent，也不意味着要把它拆成一大堆小 Agent 互相调用。

为什么？因为多 Agent 之间每一次交接，都要传上下文、都要发生一次模型调用。拆得越碎，Agent 之间的沟通就越重。

我见过一个特别典型的案例——把一个本来可以一次完成的任务，拆成了四个 Agent：”规划 Agent → 检索 Agent → 分析 Agent → 总结 Agent”。结果光是它们之间互相传话、反复确认，就烧掉了比干活本身还多的 token。

正确的做法是：该上 Agent 的整体场景上 Agent，但内部的子步骤如果是确定的，就在这个 Agent 内部用 Workflow 式的固定逻辑串起来，别拆成更多子 Agent。Agent 负责那个不确定的主干决策，确定的枝节用 Workflow 收进来。

能用 Workflow 的别上 Agent，非上 Agent 不可的，也别拆太碎。

第二层：别全程顶配，按场景分模型

确定了哪里真的需要模型之后，第二个决策是：每个环节用哪个模型？

很多人有个惯性思维——”全程用最好的”，从头到尾顶配。只要你看账单衡量一下消耗和产出，就能很明显觉得需要有分级：

难活派给贵的、聪明的；简单活派给便宜的、够用的。

那些真正需要强推理、容错率低的环节——复杂决策、高质量代码生成——值得上最强模型，因为这里质量直接决定成败，省不得。而那些大量常规的、确定性高的环节——分类、抽取、格式化、简单问答——用便宜模型完全够用。在高频调用下，这一项省下来的可能是数量级的差异。

但有个重要的例外

对小公司、小团队来说，有时候第一版直接上最贵的模型，反而是对的。

为什么？因为 Agent 落地的初期，最大的风险不是成本，而是员工不信任它、觉得它不聪明，然后直接弃用。这个阶段，让员工第一次用就感觉到”这东西是真聪明”，建立起信任，比省那点钱重要得多。而且小公司的文件体量、调用量通常不大，贵模型和便宜模型的绝对费用差距其实很小——你省下的几十块钱，可能换来的是整个团队对 AI 的抵触。

所以这一条要辩证看：成本优化是为业务服务的，不是为省钱而省钱。判断标准永远是”这一步的钱花得值不值”，而不是”贵的就浪费”。

分诊机制：便宜模型当前台，贵模型只看专家号

“按场景分模型”是原则，落地的时候你需要一个具体的机制来执行它。这个机制叫”分诊”。

逻辑跟医院一模一样——不是所有病人一来就挂专家号，而是先经过分诊台。一个便宜、快速的小模型先接住所有任务，简单的它自己当场处理掉，只有真正复杂、它拿不准的，才升级转交给贵模型。

那么问题哪些问题用便宜的，哪些问题用贵的呢？

轻量模型

• 文本分类、意图识别、打标签
• 固定格式的信息抽取
• 简单问答、改写、摘要
• 格式转换（表格↔文字、文字→JSON）

强模型

• 复杂推理、多步逻辑决策
• 高质量代码生成、复杂系统设计
• 长程 Agent 任务、复杂工具调用编排
• 多模态理解（图/音/视频）
• 高价值、低容错的对外场景

为了更直观的举例，我把市面上常见的大模型对照关系做成一张表（方向仅供参考，以最新版本和实测为准）：

第三层：给 Agent 装个”刹车”

说完主动省token的场景，还需要防失控。

Agent——尤其是多个 Agent 互相调用的时候——有个非常真实的危险：它可能陷进某种循环，或者越想越深，在你不知道的情况下，几分钟烧掉一大笔 token。大模型的随机性意味着，你没法百分百保证它每次都规规矩矩地停下来。

• 预算熔断。给一个任务设 token 上限，烧到这个数就强制暂停，转人工确认——”这个任务已经花了 X，要不要继续？”
• 轮次上限。给 Agent 之间的对话或调用设最大轮数，比如来回超过 N 轮还没收敛，就停下来交给人判断，而不是让它无限自循环。
• 关键节点的人工确认。在那些”一旦做错代价很大”或”即将触发大量后续调用”的节点，插一个人工确认的卡点。

与其事后看着账单心疼，不如事前给它划好不能越过的红线。不仅是省钱，也是控风险。

第四层：给每个 Agent 装个”电表”

省 token 不是一次性动作，是个持续迭代的过程。而迭代的前提是可观测。

一个非常实用的做法是：给每个 Agent——甚至每个任务——配一个 token 仪表盘，清清楚楚显示：这次任务烧了多少 token、花在哪个环节、调用了哪个模型、花了多少钱。

有了这块”电表”，很多优化才有据可依：你能看到哪个 Agent 是吞金兽，知道该优先优化谁。你能发现某个环节其实用便宜模型就够，做模型降级。你能定位某类任务总是异常地贵，去查是不是 prompt 设计或流程有问题。

看不见的成本没法管理，先让它可见。

再补几个多 Agent 协同的省钱小技巧

前面四层是骨架。既然聊到多Agent协同，再补几个更细的思路：

• 上下文别无脑全量传递。多Agent协作最隐蔽的浪费，是Agent之间传信息时，把完整对话历史一股脑全塞过去，越往后越臃肿。让上游 Agent 只传”结论/摘要”，而不是”全过程”——下游要的是结果，不是你整个思考过程的草稿。
• 结果缓存与复用。多个Agent在一个任务里，很可能重复检索同样的内容、重复问同样的子问题。建一个共享的结果缓存，相同的子任务直接复用上次结果，别重复付费。
• 设计【停】的卡点。多Agent讨论协作时，容易出现”已经得到足够好的答案了，但它们还在反复确认”的情况。设计一个机制，一旦判断”答案已经足够”就主动收敛结束。很多token是浪费在”已经够了但还在继续”上的。

写在最后

回头看这四层，你会发现一个挺有意思的规律：

省token省得最多的地方，几乎都不在“技术细节”里，而在“架构和治理决策”里。

要不要用Agent、用什么模型、给不给它装刹车、能不能看见它花了多少——这些都是在设计AI产品架构就该想清楚的判断。等到上线之后才想起在 prompt里抠字数，那是末端的小修小补，省不出量级的差异。

Token 是Agent时代的电费。而真正会省电的人，不是天天盯着电表抠那一度两度，而是在装修的时候就把电路设计对了。

你每次打开Claude，说”帮我写一份产品分析报告”，它都能给你一份看起来还不错的文档。但如果你有20个不同的任务——写报告、分析数据、写代码、回复邮件——你发现了一件令人沮丧的事：AI的表现忽高忽低，同一个任务，今天输出好，明天输出差。问题不在AI本身。问题在于：你每次都在重新发明轮子。Skill的出现，就是为了解决这个根本矛盾。

一、大多数人理解错了Skill

“Skill不就是一段提示词吗？”这是关于Skill最常见、也最有害的误解。如果你把Skill理解为”一段文字塞给AI”，那你只看到了它的表面。Skill的真实定义是：一套精心设计的能力加载机制——它要回答的是四个最基本的问题：什么时候触发，加载什么，执行什么，以及怎么迭代。

这是一个系统工程的命题，不是写prompt的命题。两者有什么区别？提示词是静态的，Skill是动态的。提示词是点对点的指令，Skill是可组合的能力单元。提示词写完就结束了，Skill需要测试、需要迭代、需要和其他Skill共存。Anthropic给Skill的定义值得原话引用：

“A skill is a set of instructions — packaged as a simple folder — that teaches Claude how tohandle specific tasks or workflows. Instead of re-explaining your preferences, processes, anddomain expertise in every conversation, skills let you teach Claude once and benefit every time.”

“教一次，永久受益”——这才是Skill的本质。它不是在告诉AI”做什么”，而是在正确的时间、以正确的方式、让AI做正确的事。这就是核心冲突所在。同样的Claude能力，有人用Skill做到90%任务成功率，有人每次从零开始只有30%。差距不在模型，在于Skill设计的质量。

二、纵向：Skill的概念不是凭空出现的

理解Skill，必须把它放回历史脉络里。它不是一次偶然的发明，而是AI能力表达方式演进的必然产物。

前Skill时代

重新发明每一次最早的AI使用方式极为朴素：用户说一句，AI答一句。没有记忆，没有上下文积累，没有能力复用。每次对话开始，AI都是一张白纸。你跟它聊了半小时的数据分析偏好，下一次打开窗口，全部归零。这意味着：所有的高质量输出，都建立在重复劳动之上。专业用户很快发现，这不是可持续的使用模式。

System Prompt时代

静态配置的死胡同2022年前后，System Prompt（系统提示词）的概念开始流行。本质上，这是把常用指令”写死”在对话开头，让AI一启动就具备某种角色或能力。这比每次重说强多了。但System Prompt有三个根本局限：

第一，无法按需加载。不管当前任务是什么，System Prompt的内容全部加载进上下文。任务越复杂，System Prompt越长，上下文膨胀越严重。Anthropic的文档里特别指出了这一点——大量Skill内容一股脑塞进SKILL.md，正是最常见的错误之一。

第二，不可组合。 多个System Prompt互相干扰的情况极为普遍。当你有一个”数据分析专家”的System Prompt和一个”代码审查员”的System Prompt，二者同时存在时，AI的行为往往互相矛盾，因为没有清晰的加载和触发机制。

第三，无法迭代。 System Prompt是”一锤子买卖”，写完即定型。没有内置的测试、验证、反馈机制，你只能靠感觉判断效果好坏。

Plugin/GPTs时代

能力扩展的第一次尝试2023年，OpenAI推出Plugin生态和GPTs，试图解决能力扩展问题。用户在ChatGPT里”装”一个插件，就能让AI访问外部API、获取实时数据、执行特定操作。

这代表了重要的范式转变：AI开始从“回答问题的工具”进化为“执行任务的工具”。

但Plugin体系有一个根本缺陷：强耦合，不可组合。GPTs的Actions本质上是OpenAPI规范的包装——你把API描述告诉AI，AI根据描述决定是否调用。这种模式的局限在于：API能做什么是固定的，AI只能在其范围内工作。

更关键的是，一个GPT里的多个Action互相不知道对方的存在，无法协调完成需要跨服务的工作流。

简单说：Plugin时代解决的是”AI能调用什么工具”的问题，但没有解决”AI在什么场景下该用什么工具、工具之间怎么协作”的问题。

Skill时代：质的飞跃

2024年底到2025年初，Anthropic正式推出Claude Skills。与Plugin相比，Skill体系实现了三个关键跃迁：

渐进式加载（Progressive Disclosure）。 这可能是Skill设计里最深刻的创新。它将能力加载分为三个层次：

第一层是YAML frontmatter，永远加载，但极轻量（约100个token），只够让AI”知道”有这项能力存在；

第二层是SKILL.md正文，按需加载，包含完整的执行指令；

第三层是references和scripts，按需深入，提供细节支撑。token是稀缺资源。

渐进式加载的本质是：不是所有能力都需要同时在场。这是一个关于”何时加载什么”的设计哲学，而不仅仅是技术实现。

• 可组合性（Composability）。 Claude可以同时加载多个Skill，每个Skill之间有清晰的边界，互不干扰。这意味着Skill是真正的模块化单元——你可以同时拥有”报告生成”Skill和”代码审查”Skill，它们各自工作，互不冲突。
• 可移植性（Portability）。 同一个Skill在Claude.ai、Claude Code和API中行为一致。这打破了”平台绑定”的魔咒——你在本地调试好的Skill，上传到任何支持的平台都能工作。

纵向梳理到这里，核心洞察已经浮现：Skill的演化本质是从“静态配置”到“动态能力加载”的范式转变。

前两个时代的核心问题是”怎么让AI知道更多”，Skill时代的核心问题是”怎么让AI在正确的时刻调用正确的知识”。这不是同一个问题的不同答案，这是两个完全不同的问题。

三、Skill的核心设计原则

从Anthropic的官方指南中提炼出最重要的设计原则，但关键不是记住它们——而是理解它们为什么存在。

原则一：YAML Frontmatter是生死线

Skill能不能被触发，完全取决于frontmatter中的description字段写得怎么样。这不是夸张。一个Skill写完上传，系统一切正常，但Claude永远不会自动加载它——90%的原因是description没写好。description的核心结构只有三个要素：做什么 + 什么时候触发 + 关键触发词。

Anthropic给出的好description示例：

description: Manages Linear project workflows including sprint planning,task creation, and status tracking. Use when user mentions “sprint”,”Linear tasks”, “project planning”, or asks to “create tickets”.

坏的description：

description: Helps with projects.

“帮助处理项目”——这是对Skill功能的总结，不是触发条件描述。Claude拿到这个描述，它怎么判断用户什么时候需要这个Skill？它没法判断。这引出了一个反直觉但极其重要的设计原则：description不是写给人看的，是写给AI的触发判断器。它的读者是Claude的语义理解引擎，不是用户。你写的不是产品文档，是一份触发条件清单。

好的description = “做什么”（语义上清晰的能力边界）+ “触发信号”（用户可能说的话）。坏description = 模糊的功能概括。

原则二：渐进式加载是Token经济学

前文提到渐进式加载是Skill最重要的设计哲学，这里要展开它为什么重要。当你把所有内容都塞进SKILL.md，Claude每次启动都要处理这些内容。单个Skill可能还好，10个Skill同时启用，上下文窗口里堆满了各种能力描述，AI的注意力被严重分散。

更实际的影响：响应变慢，成本上升。

Claude处理每一条上下文token都要消耗计算资源，这些资源本来可以用来处理你的实际任务。Anthropic的建议很具体：SKILL.md保持简洁，把详细文档移到references/目录，按需引用。

这看起来是文件组织问题，实际上是能力加载的优先级管理问题。

具体操作上，有几个实践技巧：

• references/目录存放API文档、示例代码、详细的错误处理说明。这些文件默认不加载，只有当Claude需要深入了解某个细节时，才去引用。
• scripts/目录存放可执行脚本——比如数据验证脚本、格式检查脚本。这些脚本在Skill执行时调用，不在prompt里用自然语言描述校验逻辑。
• 代码是确定性的，语言描述不是。
• 当校验规则复杂时，用脚本比用文字说明可靠得多。

原则三：指令的具体性决定执行质量

这是Skill设计中最容易出问题的地方，也是最有改善空间的点。模糊指令：

“验证数据后继续”

这条指令的”可解释空间”太大了。什么叫验证？验证哪些字段？什么算验证通过？验证失败怎么办？Claude面对这种指令，要么自己猜测，要么反复确认，两种结果都不理想。具体指令：

“调用 python scripts/validate.py –input {filename} 检查数据格式。验证失败时，常见原因包括：缺失必填字段（将缺失字段名返回给用户）、日期格式错误（使用YYYY-MM-DD格式）。只有在所有验证通过后才能进入下一步。”

区别在于：具体指令告诉了AI用什么工具、传什么参数、预期什么输出、失败怎么处理。

这四个要素齐全，Claude的执行路径就清晰了。Anthropic在文档里特别提了一个高级技巧：对于关键验证，考虑将检查逻辑封装为脚本，而不是用自然语言描述。

这背后的逻辑很朴素：代码执行的结果是确定的，语言模型的输出具有概率性。当精度重要的时候，放弃概率。

原则四：可组合性是设计约束，不是选项

当你设计一个Skill，必须假设它不是唯一存在的。这个假设带来了具体的约束：Skill不能独占全局上下文，不能假设所有工具都可用，不能做与相邻Skill冲突的行为假设。反过来，这要求你在Skill设计时明确声明它依赖什么能力（通过compatibility字段），以及它不处理什么场景（通过description中的negative trigger）。Anthropic文档中给了一个negative trigger的示例：

description: Advanced data analysis for CSV files. Use for statisticalmodeling, regression, clustering. Do NOT use for simple dataexploration (use data-viz skill instead).

这种边界声明表面上是在”拒绝”一些场景，实际上是在保护Skill的专注度。一个什么都做的Skill，实际上什么都做不精。

原则五：可移植性从命名开始

Skill设计有一个容易被忽视的细节：文件夹和name字段的命名方式。

Anthropic的规定很清楚：使用kebab-case（全小写，横杠分隔），禁止空格、禁止下划线、禁止大写。文件夹名必须和name字段完全一致。

# 正确

name: figma-design-handoff

# 错误

name: Figma_Design_Handoff

这不是格式癖好，这是系统兼容性的基础。当一个Skill可能在Claude.ai、Claude Code和API之间迁移时，任何命名不一致都可能导致加载失败。命名规范是最基础的可移植性保障。

四、各平台Skill体系的全景对比

Skill不是Anthropic的独角戏。将它放在更宽的视野里，能更清楚地看到它的特点和局限。

对比框架

我选取四个最具代表性的平台进行对比：Anthropic Claude Skills、OpenAI GPTs/Actions、Coze扣子Bot，以及LangChain/LangGraph。

Anthropic Claude Skills：精细度的领跑者

Claude Skill体系在”能力加载的精细度”上领先整个行业。三层渐进式加载是迄今为止最优雅的上下文管理方案，它解决了Plugin时代最核心的矛盾：能力丰富度和上下文膨胀之间的张力。

YAML frontmatter作为触发判断层，是一个小而美的设计决策。只加载几百个token的元数据，让AI”感知”所有可用Skill，然后只在需要时才加载完整内容——这个思路从根本上优化了token使用效率。

但它的局限也很明显：Skill自己没有执行工具的能力，需要依赖MCP（Model Context Protocol）提供工具层。Skill告诉你”怎么做”，MCP让你”能做到”。二者结合才有完整的能力闭环。

另外，Claude Skill体系相对较新（2025年才成熟），社区生态和工具链的丰富度不如老牌平台。

OpenAI GPTs/Actions：配置驱动，但强耦合

GPTs/Actions的最大优势是门槛极低——任何人花几分钟就能创建一个能调用外部API的GPT。但这个优势同时也是它的局限所在。

Actions基于OpenAPI规范构建，本质上是把你的API描述告诉ChatGPT的模型。这解决了一个基本问题：AI怎么知道有哪些API可以调用。但OpenAPI规范是描述性的，它告诉你”接口是什么”，不告诉你”什么时候该用哪个接口、多个接口之间怎么协作”。

GPTs的多个Actions之间是隔离的，没有内置的跨Action协调机制。当你需要从Google Calendar读取事件、从Slack发送通知、再把结果写回Notion——GPTs本身无法编排这个流程，你需要自己写额外的逻辑或者借助Zapier这样的中间层。

简单说：GPTs适合单点能力扩展，不适合复杂工作流。

Coze扣子：中文生态的低代码最优解

Coze代表了另一种思路：用可视化编排降低技能构建的门槛。

Coze的Bot构建有几个核心组件：人设与提示词（相当于System Prompt）、插件（相当于工具调用）、工作流（可视化节点编排）、知识库（RAG增强）。对于非技术背景的用户，这套体系的上手成本极低——拖拖拽拽就能搭出一个能用的Agent。

工作流是Coze最有特色的部分。它用图形化界面把Agent的思维过程”外化”出来：输入→LLM节点处理→插件调用→条件分支→输出。每个节点有明确的输入输出定义，流程的每一步都是可追溯的。

但Coze也有明显的局限：它高度绑定Coze生态，一旦你投入大量精力构建了复杂的工作流，迁移成本极高。另外，可视化编排虽然降低了入门门槛，但也限制了表达复杂逻辑的上限——当流程分支足够多时，图形界面本身就变成了理解障碍。

LangChain/LangGraph：开发者的工坊

LangChain和LangGraph代表了完全不同的用户群：它们是为程序员准备的。

LangChain 1.0（2025年10月发布）提供了create_agent抽象，用几行代码就能创建一个带工具调用能力的Agent。LangGraph则在底层提供了图形化状态机，用于构建高度复杂的Agent工作流。

从技术角度，LangChain/LangGraph是目前最灵活的方案：你可以定义任何工具、任何状态转换逻辑、任何中间件处理。ReAct循环、checkpoint持久化、human-in-the-loop介入——这些高级功能都有原生支持。但代价是：这是一套代码优先的方案，需要Python/JavaScript编程能力。对于没有工程背景的用户，这是无法逾越的鸿沟。

核心判断

各平台在”能力加载精细度”上的排序是：Claude Skills > LangChain > Coze > GPTs。

各平台在”开发便利性”上的排序是：Coze > GPTs > Claude Skills > LangChain。

结论：Anthropic的Skill体系在工程设计层面确实领先，但它面向的是有一定技术理解力的用户群体。 想要真正发挥Skill的能力，用户需要理解渐进式加载的逻辑、能写出有效的description、能组织好references结构——这比在Coze里拖拽节点需要更多的认知投入。

两种路线都有其价值。市场需要低门槛的方案让更多人用起来，也需要精密的体系让深度用户构建真正可靠的生产级能力。

五、五大实战模式：从Pattern到实践

Anthropic文档提炼出了五个经过验证的Skill执行模式。这些模式不是教条，而是经过真实场景检验的工作流模板。每个模式都有其最佳适用场景。

模式一：顺序工作流编排

适用场景： 多步骤流程，每一步依赖前一步的结果，且顺序固定。

典型例子：客户入职流程——创建账户→配置支付→建立订阅→发送欢迎邮件。每个步骤的输出是下一步的输入，中途失败需要回滚。

这个模式的核心不是”步骤多”，而是步骤之间有明确的依赖关系和失败处理。

顺序编排的关键技术点：每一步明确声明依赖字段（”从Step 1获取customer_id，传入Step 3″）；每个阶段包含验证逻辑，不验证就不进入下一步；失败时提供明确的回滚指令，不是一句”出错就停止”。

Anthropic的文档特别强调：Rollback instructions（回滚指令）是顺序工作流里最容易被忽略、也最不该被忽略的部分。 如果第四步失败了，前三步做的操作需要被撤销——账户创建了但订阅失败，残留数据怎么处理？没有这一步，Skill在失败场景下会留下一地鸡毛。

模式二：多MCP协调

适用场景： 工作流跨越多个外部服务，每个服务由独立的MCP处理。

典型例子：设计-开发交接流程——从Figma MCP导出设计资源→从Drive MCP存储资源→从Linear MCP创建开发任务→从Slack MCP通知团队。

多MCP编排的挑战在于阶段分离和数据传递。

Phase 1（设计导出）完成后，资源链接需要被捕获，并作为参数传给Phase 2（存储）。Phase 2完成后，存储路径需要传给Phase 3（任务创建）。每个阶段的边界必须清晰，交接的数据必须标准化。

这个模式的另一个关键点：集中式错误处理。当某个MCP调用失败，需要有一个统一的错误处理策略——是重试几次？是跳过这个步骤继续后续流程？还是整个流程中止？不能在每个阶段各自为政。

模式三：迭代精炼

适用场景： 输出质量随迭代次数提升，且质量标准可以明确定义。

典型例子：报告生成。第一遍草稿→质量检查（脚本验证）→识别问题（缺失章节、格式不一致、数据校验错误）→针对性修改→再验证→直到质量达标。

这个模式的本质是把质量控制从“AI自己判断”变成“程序化验证”。

迭代精炼的核心不是”多生成几遍”，而是质量标准必须前置。在开始迭代之前，必须明确：什么算”高质量”报告？结构完整（包含哪些章节）？数据准确（怎么校验）？格式统一（用什么模板）？

Anthropic的文档给出了关键洞察：知道什么时候停止迭代，和知道如何迭代一样重要。 没有停止条件，Skill会陷入无限循环——每次生成都比上次稍微好一点，然后继续改，永远不输出最终版本。

设置停止条件的常见策略：验证脚本返回通过（程序化标准）；达到最大迭代次数（硬上限）；人工确认环节（human-in-the-loop）。

模式四：上下文感知工具选择

适用场景： 同样的目标，不同的工具选择取决于输入的具体特征。

典型例子：智能文件存储——根据文件类型和大小决定存储位置。大型文件（>10MB）走云存储MCP，协作文档走Notion/Docs MCP，代码文件走GitHub MCP，临时文件走本地存储。

这个模式的关键是清晰的决策树和降级方案。

决策树必须穷举所有可能的输入场景。Claude遇到一个”没见过”的场景时，应该怎么做？降级方案提供了答案：默认走最通用的选项，而不是直接报错。

另一个重要的设计点：向用户解释为什么做了这个选择。Anthropic的文档将”提供上下文给用户”作为这个模式的必要组成部分。一个透明的决策过程，既建立了用户信任，也便于用户发现问题后及时纠正。

模式五：领域专有智能

适用场景： Skill需要嵌入超出工具访问的领域知识，且涉及合规或审计要求。

典型例子：金融合规支付处理——交易前必须检查制裁名单、验证司法管辖区许可、评估风险等级。处理完成后，所有合规检查必须记录日志，可供审计追溯。

这个模式的独特之处在于：合规检查先于业务操作，审计追溯贯穿全程。

很多领域都有这样的强制约束：医疗AI在推荐治疗方案前必须检查禁忌症，工业AI在执行操作前必须验证安全条件。领域专有智能模式把这些约束内置到Skill的执行逻辑中，而不是事后追加。

这也揭示了Skill设计的一个深层原则：能力不仅仅是“能做到”，还包括“做到的方式是否符合规范”。一个支付处理Skill，如果缺少合规检查前置步骤，它的能力是不完整的。

六、最常见的三个陷阱

Skill设计有三个高频失败点。每一个都有明确的诊断方法和修复路径。

陷阱一：Skill存在，但永远不被触发

诊断：上传后测试，发现Claude从不自动加载这个Skill，每次都需要用户手动指定。

根本原因： description字段写得过于模糊或缺少触发词。

“帮助用户处理Figma相关任务”——这句话的问题在于，”处理Figma相关任务”是一个太大的语义空间。Claude在判断是否加载这个Skill时，需要在description中找到足够具体的匹配信号。

修复方案：

第一步，用Anthropic建议的方法验证：直接问Claude”你什么时候会使用[Skill名称]这个Skill？”Claude会引用它的description内容。根据引用的内容判断：是否包含了足够具体的触发场景？

第二步，增加触发词。Anthropic明确建议description中应该包含”用户可能说的话”——包括具体的文件类型（.fig、.sketch）、具体的操作动词（”导出”、”handoff”、”生成规格”）、具体的产品名称（Linear任务、Figma设计）。

第三步，如果description已经很具体但仍然不触发，检查是否有其他Skill的description覆盖了更广的范围，导致竞争。通常的解决思路是：让description更窄但更精准，而不是更宽但更模糊。

陷阱二：Skill加载了，但AI不按指令走

诊断：Skill触发了，但Claude输出的内容与SKILL.md中描述的步骤不一致。Claude忽略某些步骤，或者用自己的理解重新组织了流程。

根本原因： 指令要么太模糊、要么太冗长、要么关键指令被埋在了文件深处。

Claude的注意力有优先级。写在文件开头的内容比埋在结尾的内容权重更高。 如果关键指令在文档中间，Claude在长上下文里可能会”忘记”它们——这不是AI的缺陷，这是注意力机制的特性。

修复方案：

关键指令前置。用 ## Critical 或 ## Important 这样的标题明确标记最核心的步骤。Anthropic的文档甚至建议”如果需要，重复关键点”。

避免冗长。如果SKILL.md超过5000词，Claude的执行质量通常会下降。把详细文档移到references/目录，正文保持核心流程的精炼描述。

使用脚本替代自然语言描述关键校验。当校验逻辑复杂时，写一个 scripts/validate.py，然后在SKILL.md中用”运行 python scripts/validate.py –input {filename} 检查数据格式”来调用。代码是确定性的执行路径，不依赖模型的概率解释。

加入正面激励。Anthropic文档提了一个反直觉但有效的技巧：明确鼓励Claude慢下来、把质量放在速度前面。”Take your time to do this thoroughly. Quality is more important than speed.”——这句话写进用户的prompt比写进SKILL.md效果更好。

陷阱三：Skill本身不大，但整个系统变慢了

诊断：单个Skill性能正常，但当启用10个以上Skill时，明显感觉到响应变慢、延迟增加、输出质量下降。

根本原因：多个Skill同时加载导致上下文膨胀，或者SKILL.md设计时没有利用渐进式加载的层次结构。

修复方案：

减少同时启用的Skill数量。Anthropic建议评估是否同时启用了超过20-50个Skill。如果是这样，考虑使用”Skill Pack”策略——把相关能力打包成更少、更大的Skill，而不是维护几十个细粒度Skill。

充分利用三层加载结构。frontmatter只放触发元数据（<1024字符），SKILL.md正文放核心指令（<5000词），references/放深度文档（在SKILL.md中按需引用）。

SKILL.md内部也用渐进式。 在SKILL.md正文中，不要一次性铺开所有细节。用”## Overview”介绍整体流程，在需要时才深入到”### 详细步骤”。这种结构本身也是一种渐进式——Claude可以先获取高层理解，再按需加载细节。

七、Skill设计的深层逻辑

把纵向的演化脉络和横向的平台对比交叉，能看到一些单从任何一个维度都看不出的东西。

洞察一：Skill的本质是”能力的编译”

提示词时代，AI能力的传递依赖”文字”——人写一段话，AI读一段话。文字天然具有歧义性，同一句话在不同上下文里有不同理解，这导致了提示词的不稳定性。

Skill不是文字，是经过结构化组织的知识模块。YAML frontmatter提供元数据，SKILL.md正文提供执行指令，references/提供深度支撑，scripts/提供确定性执行路径。这套结构将人的隐性知识——知道什么时候该做什么、怎么做——编译成AI可解析、可执行、可验证的显性指令。

“编译”这个比喻值得深想。编译器处理源代码，输出机器指令。好的编译器做优化——删除冗余代码、重排执行顺序、缓存中间结果。好的Skill设计者做同样的事——删除冗余的指令描述、优化触发条件的精确度、把模糊的”尽量做好”编译成精确的”在X条件下执行Y动作”。

从这个角度看，Skill写得好不好，本质上不是”文笔好不好”，而是编译质量高不高。

洞察二：Skill是AI Agent范式演进的锚点

从更宏观的视角看，AI Agent领域正在经历一个核心转变：从”模型输出”到”系统执行”。

早期Agent（如AutoGPT，2023年4月）试图让模型自主决定整个行动计划，代价是极度不可靠——模型会陷入循环、调用错误的工具、无法从错误中恢复。

LangChain的ReAct模式（Reasoning + Acting）推进了一步：明确让模型在”思考”和”行动”之间交替，每次工具调用后都让模型审视结果再决定下一步。这提高了可靠性，但也带来了新问题：模型在每个循环里都要”想一下该怎么做”，这本身就是token和时间上的浪费。

Skill提供了一个不同的解决思路：把“知道该怎么做”这件事本身结构化。模型不需要在每次执行时都从头推理”这个多步骤任务应该先做什么再做什么”——Skill已经把这条路经编码好了。模型只需要在Skill的框架内处理当前的具体输入。

这意味着Skill不是在”控制”AI，而是在”卸载”重复推理的负担，让模型把注意力集中在真正需要判断的地方。

洞察三：Skill的成熟度决定Agent能力的上限

AI Agent目前面临的核心矛盾是：模型越来越聪明，但可靠执行复杂任务的能力仍然有限。 原因不在模型本身，在于”怎么组织能力”这个工程问题还没有被很好地解决。

Skill体系正在尝试解决这个问题。它的五个设计原则——渐进式加载、可组合性、可移植性、具体性指令、领域嵌入——对应了五个真实的能力缺口：上下文管理、多Skill协作、跨平台迁移、执行可靠性、垂直领域合规。

这五个问题解决到什么程度，AI Agent就能从”聊天机器人”进化到什么程度。

洞察四：Skill的未来——从手写到自生成

当前Skill还需要人工编写。但这个状态不会持续太久。

几个信号已经出现：Anthropic内置了skill-creator Skill，可以根据自然语言描述自动生成SKILL.md框架。LangChain的PromptEvolver框架已经在实验自动优化提示结构的工作流。多Agent协作系统（如MetaGPT）中，已经开始用”角色编码的SOP”来自动生成Agent的行为规范。

未来的Skill很可能有两层：基础层是结构化模板（由平台或框架预制），个性化层由用户通过自然语言描述生成。就像现在的网页模板——大多数人用现成模板，少数人从零手写。

但即使在那时，理解Skill的底层设计原则仍然重要。你不需要成为模板设计师，但你需要知道为什么一个模板有效、另一个模板失败。

八、结尾

Skill不是给AI写说明书，是给AI装手艺。

说明书是死的参照物，用的时候查一下，用完放回去。手艺是活的执行能力——它是身体的一部分，不需要每次调用都从零想起。

说明书式的AI使用方式，每一次任务都是从零建立上下文。你以为你在”用AI”，实际上你在反复做知识搬运的工作，把你脑子里的隐性经验一遍遍翻译成AI能理解的文字。

手艺式的AI使用方式，是把那些反复用到的知识和流程编译成Skill，让AI在正确的时间自动调用它们。你只需要在关键时刻做判断、做校正、做升级。

这个转变的难度不在于技术，在于认知。

大多数人还在用”说明书思维”使用AI——每次把任务描述一遍，等AI给一个答案，下次再描述一遍。这是一个令人疲惫的循环，也是AI表现不稳定的根本原因。

Skill是一扇门。打开它，AI就不再是你每次用完就忘的工具，而是会积累、会进化、会在下一次自动做得更好的执行者。

至于门后面是什么——取决于你愿意把多少”手艺”装进去。

故事是这样的。

两个月前，我在朋友圈刷到一张截图。一个朋友用某个AI工具，10分钟写完了产品需求文档，5小时发布了微信小程序。

我当时就愣住了。

作为一个干了十多年的产品经理，我写个PRD至少得折腾半天，调格式、画流程图、写用例…结果现在AI告诉我，这些可以5分钟搞定？？？

说实话，我是不信的。

但好奇心还是驱使我下场了。我想看看，这些吹得天花乱坠的Claw类AI Agent，到底是真本事还是智商税。

于是，我开始了为期两个月的实测。

先说说我的情况

在正式开测之前，得先交代一下背景，不然你看完可能会说”你这不适合我”。

我目前的状态是：

• 公司电脑不允许本地部署任何东西，必须用云端方案
• 家里个人电脑可以本地折腾
• 核心需求是AI辅助写需求文档、联动飞书、做产品原型、还有公众号自动推送
• 我的关注优先级：部署门槛 > 使用成本 > 场景适配 > 稳定性 > 拓展性

好，交代完毕，开测。

一、OpenClaw：极客的玩具，产品经理的噩梦

OpenClaw应该是现在最火的开源Claw框架了。

2026年初开源后，这玩意儿直接从极客圈破圈到全行业，国内各大云厂商纷纷上线基于它的云端服务，甚至还催生了一条完整的「付费安装代运营」产业链。

我测的第一个就是它。

当时找了个周末，雄心壮志地准备部署。想着有豆包指导，应该不难吧？

结果…

前前后后折腾了整整两天。版本兼容性问题、环境配置报错、依赖冲突…豆包给的指令一堆是错的，得自己不断试错。到最后我都有点怀疑人生了。

好不容易部署成功了，出于对安全性的顾虑和token消耗的焦虑，我只敢简单测试了一下，没敢深入用。

优点嘛，确实有：

• 完全开源，本地部署，能力天花板很高
• 灵活度极高，想怎么折腾都行

但短板太致命了：

• 落地门槛极高，不只是部署本身，前置环境准备、报错排查，对非技术出身的产品经理极其不友好
• 没有开箱即用的能力，部署完所有流程和技能都得自己装
• 开源框架天然有安全风险，隐私泄露的担忧始终存在

适合谁？

有代码基础、想极致自定义工作流程的技术向产品经理，或者有技术团队支持的产品负责人。

对我来说，太折腾了。

二、妙搭版OpenClaw：免费体验卡，用完就超

因为公司电脑不能本地部署，我开始寻找云端版本。第一个找到的就是飞书妙搭基于OpenClaw开发的云端一键部署版。

优点：

• 云端一键部署，不用折腾本地环境，办公电脑也能用
• 有免费额度，可以零成本体验
• 和飞书生态打通较好，自带飞书相关skill

但问题来了。

免费额度小得可怜，问了几个问题就超了。超额后直接无法使用，没有任何提示。我当时一脸懵逼，后来在飞书上才发现超额通知。

更离谱的是排障机制。

ArkClaw和WorkBuddy遇到配置问题，直接在Claw内部对话就能解决。但妙搭不行，它有一个专属的AI机器人来处理环境配置问题，而这个机器人有单独的免费额度和收费规则——免费次数只有20次，用完要额外付费。

我实测遇到过修改模型参数后工具直接挂掉，最后只能通过这个付费机器人才恢复。

使用限制太多了。

适合谁？

想零成本体验OpenClaw基础功能、又不想折腾本地部署的产品经理，适合尝鲜，不适合深度使用。

三、ArkClaw：我的日常主力，云端部署的最优解

这是我现在日常使用频率最高的工具。

字节火山云的Claw产品，云端部署，完美适配我办公电脑无法本地部署的限制。

为什么选它当主力？

首先，部署门槛极低。云端一键部署，不用配置环境、不占本地资源，开箱即用。对非技术出身的产品经理非常友好。

其次，成本可控。我现在用的最低档套餐，ArkClaw服务器+Coding-Plan-Lite每月18000调用量，首月49，续费99。调用量比token耐用，单次简单对话消耗在个位数，日常完全够用。

还有，运行稳定。用了这么久很少出故障，不需要频繁排查bug。官方skill市场也有一定安全性筛选，比直接用开源的靠谱。

但也不是没有短板：

• 云端部署，涉及文件文档都得通过飞书，本地操作执行不了
• 对外IP会动态变化，不能稳定对接需固定IP的API接口，比如推送公众号时的IP白名单
• 不支持接入本地大模型，拓展性受限

适合谁？

办公电脑无本地部署权限、核心需求是日常产品办公提效、不想折腾环境与代码，尤其适合飞书生态重度使用者。

对我来说，这就是目前云端Claw的最优解。

四、WorkBuddy：我的本地最优选择

这是我目前搭配ArkClaw同步使用的本地部署的Claw产品。

主要用来承接ArkClaw无法完成的本地操作和固定IP接口对接需求，和云端工具形成能力互补。

优点：

• 门槛低，下载安装即可，无复杂部署
• 零成本入门，每日送100积分，每7天送1000。我用到现在还没产生过费用
• 本地部署权限充足，涉及本地的场景全部可以搞定，IP相对固定，补齐了云端工具的短板
• 全流程对话式操作友好，从模型部署到问题排查、配置修改，全程对话完成

短板也很明显：

• 对本地模型的支持有限，我试了俩模型都无法调用skill
• 处理多步骤复杂长流程任务时容易卡住，一直在执行但不知道是否正常，稳定性不足
• 配套小程序端功能尚不完善

适合谁？

有本地部署诉求，需要处理本地产品文档，或对接固定IP接口需求的使用者。

五、QClaw：腾讯出品，但令人失望

这款是腾讯电脑管家团队开发的，定位安全版OpenClaw。

在WorkBuddy使用本地模型遇到问题后，我对QClaw抱有极大期待。毕竟腾讯官方出品，安全性和合规性应该有保障。

优点：

• 腾讯官方出品，合规性与安全性有背书
• 安装简单，类似WorkBuddy，下载安装即可
• 每日4000万免费token，纸面额度很高

但实测结果令人失望：

• 稳定性较差，频繁出现网络繁忙，达不到日常高频使用标准
• token消耗效率极低，随便几个带搜索分析的问题就消耗上百万token
• 没有原生的图形化本地模型切换入口
• 整体功能和使用体验均不及同类型其他产品，无突出核心竞争力

适合谁？

想零成本体验OpenClaw基础功能、可以本地部署的场景，免费token额度比妙搭高。

我的真实使用场景

测了一圈下来，我现在日常在用的只有ArkClaw和WorkBuddy两款，二者形成能力互补，通过飞书云文档联动。

具体场景：

产品原型&demo

办公电脑用ArkClaw。可以做出示例页面，带动效交互，可云端部署外网访问，演示效果非常好。

产品需求文档

尝试过多个skill，但效果都比较一般。背景描述和文档结构还可以，但核心内容都不行。

还记得开头那个朋友圈截图吗？10分钟写完PRD的那个。

说实话，我实测下来，对于独立、简单、标准的场景，Claw确实可以做得不错。但一遇到有大量依赖关系、涉及公司级复杂产品的需求，它就到不了可用的程度。

要到真正可用的程度，还需要花时间调教，目前还无法直接用。

搜索、对话、文档编辑

相比豆包这类产品，Claw可以在授权后搜索飞书个人知识库，基于私有文档对话。支持飞书文档编辑，对于重复性的表格更新执行得很好。公域信息检索分析能力和豆包类似。

公众号运营

有专门的skill可用，可以做到定时检索分析资讯、自动选题、生成内容、推到公众号草稿。

写在最后

两个月测下来，我的感受是：

Claw类AI Agent确实在进化，但还没到你想象中的那个程度。

它可以帮你提效，但无法替代你的思考。它可以帮你生成内容，但无法替代你的判断。它可以帮你搭建原型，但无法替代你的产品sense。

工具永远是工具，关键还是看用它的人。

另外，需要说明的是，我这篇文章里提到的各种问题，可能在你看到的时候已经解决了。毕竟这些工具都在以周甚至以天为单位快速迭代，今天的问题明天可能就修复了。

ArkClaw+WorkBuddy的组合，目前是我找到的最适合自己的方案。云端用ArkClaw，本地用WorkBuddy，两者互补，基本覆盖了我所有的使用场景。

但你的场景可能完全不同，我的选择不一定适合你。

如果你也在用Claw类工具，欢迎交流。毕竟在这个快速变化的AI时代，没有谁是全知全能的，我们都在摸索中前进。

谢谢你看我的文章，我们，下次再见。

2026 年 2 月，OpenAI 官方博客发布了一篇震撼业界的文章：《Harness Engineering: Leveraging Codex in an Agent-First World》。

文章讲述了一个看似不可思议的实验：一个仅有 3 人的工程师小组，在完全禁止手写代码的条件下，利用 AI Agent 在 5 个月内构建了超过 100 万行代码的完整产品。

人均每天合并 3.5 个 Pull Request，团队吞吐量从传统的 0.25 人/工程师跃升至 3-10 人/工程师。更令人惊讶的是：新成员越多，整体效率反而越高——这就是所谓的”知识飞轮效应”。

这个实验揭示了一个深刻的认知转变：软件工程正在经历继瀑布模型到敏捷开发、单体架构到微服务架构之后的第三次重大范式转移。

那么，什么是 Harness Engineering？它与我们熟悉的 Prompt Engineering、Context Engineering 有何本质区别？作为产品经理或技术负责人，我们该如何在自己的团队中落地这套方法论？

本文将结合 OpenAI、Anthropic、LangChain 等权威机构的实践案例，尽可能的从产品视角拆解 Harness 工程化的四大核心模块，并提供可立即落地的实战指南。

一、什么是 Harness？从”马具”隐喻说起

1.1 Harness 的本质定义

“Harness”这个词的原意是马具——缰绳、鞍具、嘴套，是骑手用来连接、保护、控制马匹的整套装备。

用它来描述 AI Agent 的管理框架，比喻非常精准：

• 马（模型）：强大、快速，但不知道该往哪跑。它有巨大的能力，但没有方向感。
• 骑手（工程师）：提供方向和判断，但不自己去跑步。负责决定做什么和为什么。
• 缰绳（Harness）：连接骑手和马，确保力量被正确引导，防止失控。它不做实际工作，但让工作成为可能。

LangChain 工程师 Vivek Trivedy 给出了一句精炼的定义：

“如果你不是模型，你就是 Harness。”

这句话精准地概括了 Harness Engineering 时代工程师角色的根本转变。

1.2 从 Prompt 到 Context 再到 Harness：三次范式演进

我们可以用同心圆式的嵌套关系来理解三者的演进：

Harness Engineering 的哲学基础可以用四个字概括：“约束换自主”。

这是一个看似悖论却极其深刻的思想：规矩越明确 → Agent 独立做的事越多；约束越严格 → 信任越高 → 自主权越大。

二、方法论：Harness 工程化的四大核心模块

模块一：地图而非百科全书——对抗上下文稀缺

2.1.1 OpenAI 的教训：为什么不能把一切都塞进 AGENT.md？

在 OpenAI 的实验中，他们就发现了一个常见误区：试图把巨大的信息塞进一个巨大的 AGENT.md 文件里。

这种做法的问题在于：模型的上下文窗口是稀缺资源。巨大的指令文件会挤掉重要的任务信息、代码片段和中间结果，导致 Agent 在执行过程中”失忆”或”注意力分散”。

2.1.2 正确做法：AGENT.md 作为导航地图

OpenAI 团队的做法是：将 AGENT.md 设计为一个约 100 行的目录文件，指向结构化的文档目录。

# AGENT 核心记忆文件（导航地图）

## 项目架构

– 参见 `/docs/architecture/system-design.md`

– 参见 `/docs/architecture/data-flow.md`

## 编码规范

– 参见 `/docs/coding-standards/python.md`

– 参见 `/docs/coding-standards/frontend.md`

## API 配置

– 参见 `/config/api-endpoints.json`

– 参见 `/config/environment-variables.md`

## 关键约束

– 所有数据库操作必须通过 Repository 层

– 禁止在 Controller 中直接调用外部 API

– 所有接口必须有单元测试，覆盖率不低于 80%

## 历史决策记录

– 参见 `/docs/decisions/2026-03-20-orm-selection.md`

– 参见 `/docs/decisions/2026-03-21-error-handling.md`

Agent 拿到这张”地图”后，可以按需跳转检索具体文档，而不是把所有内容一次性加载到上下文中。

2.1.3 记忆力机制和经验库

除了静态文档，Harness 还需要提供动态的记忆力机制：

• 持久化记忆：Agent 学到的新知识、团队的新规范，自动写入 AGENT.md 或专门的记忆文件，下次启动时自动加载。
• 经验库：将常见的错误模式、最佳实践、陷阱案例整理成结构化数据，Agent 在执行前可以快速检索参考。

产品启示：不要试图让 Agent”记住一切”，而是给它一张清晰的地图，让它知道去哪里找答案。这就像给新员工一本员工手册的目录，而不是把整个公司的制度打印出来塞给他。

模块二：机械化架构约束——从”软性建议”到”硬性卡口”

2.2.1 拒绝”建议式”软性约束

很多团队在引入 AI Agent 时，会在 Prompt 中写下这样的约束：

“请遵循 MVC 架构，不要在 Controller 中直接调用数据库。”

“请编写单元测试，确保代码质量。”

这种建议式软性约束的问题在于：它依赖 Agent 自身的“自觉性”和“记忆力”。当上下文变长、任务变复杂时，Agent 很容易忘记或绕过这些约束。

2.2.2 正确做法：Hook + 结构化测试

Harness Engineering 的核心原则是：用自动化工具把约束写进执行流程里，不依赖 Prompt 的软性约束以及 Agent 自身的自觉性。

具体做法是：采用 Hook 和结构化测试，即在 Agent 执行某个操作后，自动触发一段检查程序。

原则：仅在模型出错的问题上设置约束，将”好/不好”量化成 0/1，判断是否进入下一步，作为下一步的关键令牌。

这和状态机单向通行一致：每一层必须由上一层审查无误后可推进到下一步的进程，仅允许单向逐层通行，违反则自动报错，重新执行。

2.2.3 Claude Code 的 Hooks 系统：24 个生命周期事件 × 6 种处理器类型

Anthropic 的 Claude Code 提供了一个成熟的 Hooks 系统，可以作为参考标杆。

24 个生命周期事件覆盖了 Agent 执行的各个阶段，例如：

• SessionStart：会话开始
• PreToolUse：工具调用前
• PostToolUse：工具调用后
• PreCommandExecute：命令执行前
• PostCommandExecute：命令执行后
• PreFileWrite：文件写入前
• PostFileWrite：文件写入后
• SessionEnd：会话结束对外暴露的 4 类处理器:内部使用的 2 类处理器:

2.2.4 实战示例：强制代码规范检查

假设我们希望 Agent 在提交代码前自动运行 Lint 检查，不符合规范的代码不允许提交。

传统做法（软性约束）：

在 Prompt 中写道：”请在提交代码前运行 eslint，确保没有错误。”

问题：Agent 可能忘记，或者为了省事跳过这一步。

Harness 做法（硬性卡口）：

// 在 PostFileWrite Hook 中注册检查

hooks.register(‘PostFileWrite’, async (context) => {

if (context.file.path.endsWith(‘.ts’) || context.file.path.endsWith(‘.tsx’)) {

const result = await executeCommand(‘npx eslint ‘ + context.file.path);

if (result.exitCode !== 0) {

// 返回 exitCode 2 表示阻断

return { exitCode: 2, message: ‘Lint 检查失败，请修复后重试’ };

}

}

return { exitCode: 0 };

});

这样，无论 Agent 是否“记得”运行 Lint，系统都会自动拦截不符合规范的代码。

产品启示：好的 Harness 不是让 Agent”更聪明”，而是通过协议约束让 Agent”无法偷懒”。将人类的品味和标准编码成自动化规则，实现”品味捕获一次，强制执行无限次”。

模块三：反馈闭环——让 Agent 不再”蒙眼狂奔”

2.3.1 为什么 Agent 需要反馈？

Agent 没有办法像人一样去理解页面、理解操作是否做得对。不能获得反馈的 Agent，就像蒙眼的烈马——它可能跑得很快，但方向可能是错的。

即时的反馈能够确保每一个 Agent、在每一个时间点都知道：

• 做到哪里了
• 做得对不对
• 下一步要做什么

2.3.2 分层实现反馈机制

正确的做法是：分层实现反馈机制，从即时到跨对话逐层递进，相互补充。

2.3.3 GAN 架构：规划 – 评估 – 生成

一种高效的反馈闭环设计是借鉴 GAN（生成对抗网络）的思想，构建多角色协作架构：

• 规划者（产品经理角色）：负责任务拆解、目标设定、路径规划
• 生成者（开发工程师角色）：负责代码实现、功能开发
• 评估者（QA 工程师角色）：负责质量检查、测试验证、提出改进建议

这三个角色可以是同一个 Agent 在不同阶段的切换，也可以是多个独立的 Agent 协同工作。关键在于：每个角色都有明确的职责边界和反馈机制。

2.3.4 LangChain 的实践：Trace Analyzer Skill

LangChain 在优化 Deep Agents 时，发现人工排查成千上万行运行轨迹（Trace）几乎不可能形成快速迭代。

于是他们开发了一套Trace Analyzer Skill，将”读日志找问题”这件事做成了一个可复用的系统组件：

三步流程：

抓取数据：从 LangSmith 日志平台，把这次实验里所有 Agent 的运行轨迹原始数据全部拉下来。

并行分析：系统按批次把这些 Trace 切分开，同时启动多个分析子 Agent 并行跑。每个子 Agent 负责一批，专门做错误分析。找到报错点之后，所有子 Agent 的结论汇总到一个主 Agent 那里，由主 Agent 统一提炼成结构化的发现和改进建议。

人工审查：主 Agent 给出的是”下一次实验要改什么”的完整建议清单。工程师在这里参与，核对建议是否合理，批准后才进入下一轮改动。很重要的一点是：改动必须是通用的，对特定任务过度拟合的修改，可能让其他题目的表现退步。

这三步加在一起，把原来需要几个小时的日志排查，压缩成一个可以快速循环的工程流程。

追踪记录（Traces）是整个改进闭环的核心信号。很多所谓”模型不够聪明”的问题，其实是系统没有在合适的时机，把正确的上下文和约束交给模型。没有 Trace，就无法定位这种缺口，问题只会被归结为”模型能力不足”。

产品启示：Agent 的提升不只是模型能力问题，更是系统设计问题。建立可重复、可自动化的反馈闭环，比单纯优化 Prompt 更有效。

模块四：熵管理——把代码债当作垃圾回收

2.4.1 为什么需要熵管理？

Coding 工具生成代码会积压很多的技术债，可以理解成一种文档漂移、架构侵蚀和风格异化。如果不进行管理，那么将逐步累积，越来越难维护，被逐渐腐蚀。

这种现象被称为代码熵增——随着时间推移，代码库会自然地趋向混乱和无序。

2.4.2 正确解法：持续运行，定期回收

正确的做法是：把代码熵的管理当作编程语言的垃圾回收（Garbage Collection）来看待，是一种持续运行、定期回收的状态。

具体做法包括：

把编码原则固化为 Linter 规则：通过规则编码为自动化检测，比如命名规范、修复错误信息。

后台定期 Agent 扫描：专门的清理 Agent 进行周期性的运行扫描，检查文档不一致、约束违规、架构飘逸。例如：

• • 检查注释与代码的一致性
  • 检查是否有 Controller 直接调用数据库的代码
  • 检查是否有重复代码块

生成代码健康日报：每天自动生成一份代码库健康报告，列出发现的问题和建议。

发现问题立即修复：而非以后再说的 backlog。Agent 发现一个重复代码块，立即提取为共享函数/工具/原语工具。

2.4.3 OpenAI 的金句：品味捕获一次，强制执行无限次

OpenAI 团队有一句非常精炼的概括：

“Taste captured once， enforced infinitely.”

品味捕获一次，强制执行无限次。

这意味着：把你讨厌的一切模式（重复代码、缺少重试、加密库不标准、前端组件过大……）全部写成 Lint 规则 + 测试 + 审查 Agent，直接静态禁止。

更绝的是：把团队里每个工程师的“品味”和“专长”全部编码进代码库。新来的前端大牛把 Hooks 拆小的偏好、后端专家对异常处理的坚持，都可以变成自动化规则，永久生效。

2.4.4 为删除而构建：Start Simple, Build to Delete

Harness 的设计也不是一成不变的。今天复杂的管线任务，明天可能一个提示词就搞定了。

因此，Harness Engineering 的一个重要原则是：为删除而构建（Build to Delete）。

• Start simple（从简单开始）：不要一上来就搞复杂的控制流，先提供稳健的原语工具。
• 模块化设计：让每个组件都可以独立地替换或删除。
• 定期审视：随着模型能力的提升，某些 Harness 组件可能变得多余，应该果断删除。

这体现了 Harness 工程的现实主义哲学：Harness 本质上是在为当前模型的短板提供临时支撑，随着模型进化，这些补丁会逐步消失。

产品启示：好的架构不是追求永恒的完美，而是在解决今天问题的最简单架构的同时，为明天升级留足空间。定期”修剪”你的 Harness，保持其简洁和高效。

三、实战项目：从理论到落地

3.1 LangChain：控制变量实验，排名从第 30 跃升至前五

背景

2026 年 3 月，LangChain 官方发布了一篇题为《Improving Deep Agents with Harness Engineering》的文章，展示了他们如何通过优化 Harness，在不改变模型基座的前提下，让 Deep Agents 的跑分从 52.8 提升到了 66.5，从榜单第 30 开外一路进到前五。

实验设计

他们刻意把 Harness 优化空间压缩到三类变量：

1. 系统提示词（System Prompt）
2. 工具体系（Tools）
3. 中间件 Hook（围绕模型和工具调用的中间件）

保持模型不变，只调整这三个 Harness 变量，观察性能变化。

关键改进点

改进一：强制模型自检

LangChain 在 Trace 记录里发现，最常见的失败模式是：Agent 写完代码，回头读了一遍自己刚写的内容，觉得逻辑上看起来没问题，然后直接停工宣告完成。它根本没有去运行测试，拿实际的执行结果来验证。

针对这个问题，LangChain 上了两道防线：

• 第一道：提示词层面的约束。在系统提示词里明确规定四步走的解题框架：规划 → 构建 → 验证 → 修复。特别强调：验证时必须拿结果去对照最初的任务要求，而不是去对照自己写的代码。
• 第二道：系统层面的卡口。加入完结前检查中间件（PreCompletionChecklistMiddleware）。当 Agent 准备退出、宣告完成时，系统会直接拦截它，强制要求它对照任务规格做一次验证，确认跑过测试后才允许退出。

改进二：上下文注入——给 Agent 提供环境和约束信息

Agent 对自己所处的环境、约束条件和评估标准了解得越多，它就越能自主地指导自己的工作。LangChain 做了三件事：

注入工作环境地图：Agent 一启动，系统自动扫描当前工作目录、父子文件夹结构、工具路径以及 Python 安装信息，把这些环境信息结构化后直接注入上下文。

明确自动评估标准：在系统提示词中明确声明：产出会直接被自动化测试评估，任务规格里提到的文件路径必须严格遵守，否则自动评分会失败。

注入时间预算：当接近截止时间时，系统引导 Agent 收敛问题，进入验证与收尾阶段。

改进三：循环探测中间件

在大量 Trace 日志里，存在一个典型问题：当 Agent 确定了一个方向后，会高度执着地推进。即使路径已经走不通，它仍会在同一个文件上反复做微小修改，尝试局部修补，而不是整体重审。这种现象被称为 Doom Loops。

LangChain 的解决方式是加入 LoopDetectionMiddleware：通过工具调用的钩子，持续记录每个文件的编辑次数。当某个文件的修改次数超过阈值时，系统向 Agent 上下文中注入提示，要求它重新审视整体方案，而不是继续局部修补。

改进四：算力分配策略——“推理夹心”

后台多步思考的推理型模型通常有不同的推理强度档位。LangChain 采用了一个直观有效的策略：“xhigh-high-xhigh”。

• 规划阶段使用 xhigh：理解任务、制定整体方案最容易决定成败，值得投入更高算力。
• 中间实现阶段降到 high：按计划写代码，不需要每一步过度推演，节省大量时间。
• 最后的验证与收尾阶段，再拉回 xhigh：查错、确认结果需要谨慎。

这种分段式算力分配，把最终分数推到了 66.5%。

成果

通过上述 Harness 优化，LangChain 的 Deep Agents 在 Terminal Bench 基准测试中的得分从 52.8 提升到 66.5，排名从第 30 名以外跃升至前五。

核心洞察：模型能力决定上限，而 Harness 决定你能逼近上限多少。

3.2 Gstack：个人开发者的 Harness 标杆

背景

在日常开发中，我们常常陷入一种困境：向 AI 助手请求功能，它确实写出了代码，但代码能跑却不符合业务逻辑，或者缺少关键的错误处理。我们花费大量时间修正 AI 生成的”字面正确但语义错误”的代码，本质上是因为通用助手缺乏对工程上下文的深度理解。

它们像是一个只会听令行事的初级程序员，缺乏架构师的全局视野和 QA 的严谨态度。

gstack 项目的出现，正是为了解决这一核心痛点。它不是一个新的模型，而是一套基于 Claude Code 的意见化工作流层，将单一的 AI 助手拆解为 CEO、工程经理、发布经理等十个专属角色，通过 slash 命令按需调用，让开发过程从”对话”升级为”协作”。

核心原理与架构设计

Gstack 的核心价值在于**”角色分离”**。传统的 AI 编程助手试图用一个模型解决所有问题，导致上下文污染和注意力分散。Gstack 通过预设的 Prompt 模板和工具链，将不同的工程任务路由给特定的”虚拟专家”。

这种设计哲学认为：代码审查应该由专注于质量的角色处理，而架构规划则应由关注业务价值的角色主导。

工作流逻辑架构：

用户指令（自然语言/命令）

↓

gstack 路由层（角色识别与上下文注入）

↓

Claude Code 核心（执行与生成）

↓

[CEO] 规划与需求分析

[Eng Manager] 代码实现与管理

[QA] 测试与质量保障

[Doc Engineer] 文档生成

[Release Manager] 发布与部署

在这种架构下，gstack 充当了中间件的角色。它不直接生成代码，而是优化输入给 Claude Code 的上下文。例如，当你使用发布命令时，gstack 会自动注入关于版本控制、changelog 生成和部署检查列表的指令，确保 AI 不会遗漏发布流程中的关键步骤。

这种**”意见化”（Opinionated）**的设计，意味着它强制执行了一套最佳实践，减少了开发者需要反复提示 AI 遵守规范的成本。

实战安装与配置

Gstack 基于 TypeScript 构建，依赖 Node.js 环境。安装过程简单：

# 克隆 gstack 仓库到本地开发目录

git clone https://github.com/garrytan/gstack.git

# 进入项目根目录

cd gstack

# 安装项目所需的 TypeScript 及运行时依赖

npm install

# 配置环境变量，此处需填入有效的 Anthropic API Key

echo “ANTHROPIC_API_KEY=你的密钥” >> .env

# 验证安装是否成功

npm run check

配置完成后，gstack 会作为 Claude Code 的插件层加载，用户可以在终端中直接通过斜杠命令触发特定工作流。

深度使用场景解析

场景一：架构规划与需求分析（CEO 角色）

在开始编码前，使用 /plan 命令可以激活 CEO 角色。通用助手往往会直接开始写代码，而 gstack 的 CEO 角色会先询问业务目标、用户场景和潜在风险。

用户：/plan 我想做一个内部使用的文件分享工具

gstack(CEO): 收到。在开始之前，我们需要明确几个关键点：

1. 目标用户是谁？内部全员还是特定部门？

2. 安全性要求是什么？是否需要审计日志？

3. 预期的并发量是多少？

4. 是否需要权限管理？如果有，权限粒度是怎样的？

…

场景二：代码实现与管理（Engineering Manager 角色）

使用 /implement 命令激活工程经理角色。它会负责代码的具体实现，同时确保符合团队的编码规范和架构约束。

场景三：测试与质量保障（QA 角色）

使用 /test 命令激活 QA 角色。它会自动生成测试用例，运行测试套件，并生成质量报告。

成果与启示

Gstack 证明了一个重要观点：即使是个人开发者，也可以通过精心设计的 Harness 体系，让 AI Agent 的表现达到专业团队的水平。

它的成功关键在于：

1. 角色分离：避免单一 Agent 承担过多职责导致的上下文污染
2. 意见化设计：强制执行最佳实践，减少重复提示成本
3. Slash 命令体系：提供清晰的操作入口，降低使用门槛

产品启示：Harness 不仅是大型团队的专利，个人开发者同样可以通过模块化、角色化的设计，构建适合自己的轻量级 Harness 体系。

四、外部核心：OpenAI vs Anthropic 的工程化路径对比

4.1 核心思想对比

4.2 演变路径

OpenAI 的路径：

1. 自动补全时代（幽灵文本）：GitHub Copilot 式的代码补全
2. 结对编程时代（IDE 里一起写代码）：Codex CLI，人类与 AI 协同
3. Agent 全委托时代（你只提需求，多个 Agent 自己规划、写代码、测试、提 PR）：Codex 桌面端应用 + GPT-5.4

Anthropic 的路径：

1. 启动期（2-4 月）：终端聊天、CLAUDE.md、基础命令
2. 爆发期（5-7 月）：IDE 集成、MCP、自定义命令、Hooks、Subagent
3. 深化期（8-10 月）：Plan Mode、背景任务、插件系统、Skills
4. 成熟期（11-12 月）：Claude in Chrome、LSP、Opus 4.5、异步 Agent

4.3 关键金句（中英对照）

OpenAI：

“Taste captured once， enforced infinitely.”

品味捕获一次，强制执行无限次。

“If you‘re not the model， you’re the Harness.”

如果你不是模型，你就是 Harness。（Vivek Trivedy, LangChain）

“Harness Engineering is about designing the environment where AI can work reliably.”

Harness Engineering 是关于设计 AI 能够可靠工作的环境。

Anthropic：

“Constraints enable autonomy.”

约束赋予自主。

“The best Harness is the simplest one that solves today‘s problem， while leaving room for tomorrow’s upgrade.”

最好的 Harness 是解决今天问题的最简单架构，同时为明天升级留足空间。

LangChain：

“Model capability determines the ceiling， while Harness determines how close you can get to it.”

模型能力决定上限，而 Harness 决定你能逼近上限多少。

“Traces are the core signal of improvement. Without them， problems are attributed to ‘model inadequacy’.”

追踪记录是改进的核心信号。没有它们，问题只会被归结为”模型能力不足”。

4.4 工程化思考借鉴

从 OpenAI、Anthropic 和 LangChain 的实践中，我们可以提炼出五条可复用的原则：

原则一：追踪即反馈

没有 Traces，就没有改进方向。建立可重复、自动化的日志分析和错误诊断流程，比单纯优化 Prompt 更有效。

原则二：代劳上下文工程

把模型需要的环境信息提前整理好，主动递给模型，而不是让 Agent 自己去发现和组装运行条件。外围喂的信息越精准，模型就越能把算力集中在真正的解题步骤上。

原则三：强制自我验证

让模型真正面对客观的测试结果，而不是主观判断。模型天然偏向接受自己的第一个答案，必须主动推一把，让它真正面对客观的测试结果。

原则四：识别并修补坏模式

循环探测、早期停止、上下文腐烂……这些都是当前模型的典型缺陷。通过工程护栏（如 LoopDetectionMiddleware、PreCompletionChecklist）提供阶段性补丁，虽然未来可能变得多余，但在今天能显著提高成功率。

原则五：为特定模型定制 Harness

不同模型在提示风格、推理节奏上都有差异。若想把某模型的表现推到极限，需为它单独跑几轮迭代。通用 Harness 只能达到平均水平，定制化 Harness 才能发挥极致性能。

五、落地指南：如何为你的团队构建 Harness 体系

5.1 从零开始：三步搭出最小可用 Harness

看到这里，你可能会觉得 Harness 很复杂。其实不是，你不用一上来就做一个完整的系统。从这三步开始，就能搭出一个能用的最小化 Harness。

第一步：搭最小化文件系统 + Git 工作区

创建一个专属的工作区，初始化 Git 仓库，写好你的 AGENTS.md 核心记忆文件，把项目规范、架构要求全写进去。这一步，就解决了 Agent 的持久化和记忆问题。

第二步：封装代码执行 + 沙箱环境，做最小闭环

用 Docker 搭一个简单的隔离沙箱，给 Agent 封装 Bash 和 Python/Java 代码执行能力，让它能自己写代码、跑代码、验证结果。这一步，就给了 Agent 自主解决问题的核心能力。

第三步：加记忆注入 + 上下文管理，解决核心痛点

写一个简单的上下文管理模块，Agent 启动的时候自动注入 AGENTS.md，上下文快满的时候自动做压缩，工具输出自动做卸载。这一步，就解决了 Agent 失忆、上下文腐烂的问题。

做完这三步，你就有了一个最小可用的 Harness，你的 Agent 能力，绝对会比你之前搭的 ReAct 循环强 10 倍都不止。

5.2 进阶：引入 Hooks 系统和反馈闭环

当最小可用 Harness 运行稳定后，可以逐步引入更高级的功能：

引入 Hooks 系统：

• 在关键操作（如文件写入、命令执行）前后注册检查 Hook
• 将团队的编码规范、安全要求编码成自动化规则
• 实现“违反即阻断”的硬性卡口

建立反馈闭环：

• 接入 CI/CD pipeline，在 PR 创建时自动运行测试和 Lint
• 部署可观测性工具，监控 Agent 执行过程中的日志、指标、性能
• 引入独立评估 Agent，定期对已完成的功能进行质量评分和改进建议

5.3 高阶：熵管理与持续优化

当 Harness 体系运行一段时间后，需要关注代码熵的管理：

定期扫描与清理：

• 后台运行一个周期性 Agent，定期扫描代码库里的技术债
• 检查过时的依赖、被注释的死代码、违反架构约束的模块
• 自动提交修复 PR，人类工程师只需审核即可

定期审视与删除：

• 每季度回顾一次 Harness 的各个组件
• 随着模型能力的提升，某些组件可能变得多余，应该果断删除
• 保持 Harness 的简洁和高效，避免过度工程化

5.4 组织变革：从”写代码”到”设计环境”

Harness Engineering 不仅是一套技术方案，更是一种组织变革。它要求工程师的角色发生根本转变：

传统工程师：

• 核心工作：手写代码
• 价值体现：代码行数、功能交付速度
• 技能要求：编程语言、框架、算法

Harness 工程师：

• 核心工作：设计让 Agent 能可靠工作的环境
• 价值体现：Agent 吞吐量、代码质量、知识飞轮效应
• 技能要求：系统设计、自动化、规则编码、反馈闭环设计

这种转变意味着：未来的程序员，核心竞争力绝对不再是手写代码的速度，而是设计 Harness 系统的能力。你能设计出越好的 Harness，就能把模型的能力释放得越充分，你的生产力就越强。

结语：Harness Engineering 的未来

很多人会问：模型越来越强，以后会不会把 Harness 的能力都吸收了，Harness Engineering 就没用了？

LangChain 给出的答案是：不会。

就像现在大模型已经很强了，但 Prompt Engineering 依然非常重要一样，未来不管模型有多强，Harness Engineering 依然是做好 Agent 的核心。

因为 Harness 从来不止是补模型的短板，更是围绕模型的智能，设计一套能落地、可控制、符合业务需求的系统。模型再强，也需要有人告诉它该往哪走，该遵守什么规则，该怎么和你的业务系统结合——这些，都是 Harness Engineering 要做的事。

Harness Engineering 的本质，是把“人类写代码”的思维，改成“为 Agent 写代码”的思维。

这不是技术的堆砌，而是一种范式的转变。它要求我们从产品的角度思考：如何让 AI 更好地理解我们的业务？如何让 AI 的输出更符合我们的标准？如何让 AI 的工作更可预测、更可控？

当你开始用这种思维看待 AI Agent 时，你会发现：真正的瓶颈不在模型，而在你为它设计的环境。

而这，正是 Harness Engineering 的价值所在。

过去一年，AI 做营销最常见的用法，还是写文案、出海报、改标题、做几个短视频脚本。大家也都看腻了。

现在，真正的变化开始了。

AI 开始往营销里最难、最费人、但又最影响结果的地方发起来进攻，那就是：

盯数据、跑测试、做筛选、调结果。

01 先别看 40 个 agent，先看它到底接走了什么活

前段时间，Relay 创始人 Jacob Bank 讲了一个很典型的案例：他把一整套营销工作拆给了 40 个 AI agents 来跑。

表面上看，最吸引眼球的是“40 个 agent”这个数字，但真正值得看的，不是数量，而是这些 agent 接走的到底是什么活。

不是那种听起来很高级、但落不到日常工作的“动脑子工作”，而是一堆原来每天都在发生、很碎、很杂、但又不能没人做的动作。

比如新视频发出去之后，自动改写成 LinkedIn 帖子和 X 的内容；

比如持续盯竞对创始人的社交平台动态；

比如每周扫一遍竞品定价有没有变化等等。

可以看到，这个案例里，不是 AI 开始替代整个营销团队了，而是营销团队里原来揉在一起的一团工作，开始被拆开了。

以前一个市场同学，可能同时要写、要发、要看、要跟、要复盘。

现在，这些动作第一次可以被一条条单独拎出来，交给不同的 agent 去接。

02 AI 接走的，不只是“写”，还有“复盘”和“跟进”

再举一个销售培训或者说销售复盘这个场景。

Jacob Bank 提到，他们会把销售和客户的会议转录交给 AI，让系统去看：

销售在哪里太早开始 demo？哪里问题没问透？哪里价值没讲清楚？

这个动作以前不是不重要，而是太难高频做。

真人销售教练贵，而且频率低；而 AI 的价值就在于，它能把这种原来高成本、低频率的复盘，变成一个可以低成本、反复跑的日常动作。

这背后其实是同一个变化：现在的 AI 不只是把东西做出来，而是继续向前，往更影响结果的地方继续推进：

• 一封邮件发完以后，值不值得再改一句？
• 一场会开完以后，哪些地方其实应该重讲？
• 一个销售动作结束以后，哪些环节该被复盘？

这些原来因为麻烦、不好做而被跳过的事，现在开始有人，不对，开始有系统盯了。

03 更厉害的地方，不是自动执行，而是开始自动测试

如果说 Relay 这一类案例，更多还是把营销动作拆开、自动执行，那现在更值得关注的一步，是 AI 开始把“测试”这件事也接过去了。

这才是这波 AI agent 真正变重的地方。

因为营销里真正难的，往往不是“做一个版本”，而是“连续试很多版本”：

• 推送要不要分人群测？
• 广告素材要不要先小流量试三轮？
• 落地页首屏标题要不要换？
• 投放策略是不是该根据早期反馈继续调？

这些事情，大家都知道重要。问题从来不是“不懂”，而是没时间、没人手、也没有足够低的成本，去把它们持续做下去。

现在 AI agent 在做的，就是这些活。

04 OpenClaw 补上的，是“持续在线”这一层

先看一个 X 上的帖子：

OpenClaw 这条线有意思的地方，不在于它是不是一个专门做 marketing 的工具，而在于它更像一个一直挂着的执行壳。

它可以接入 WhatsApp、Telegram、Slack、Discord、Teams、飞书、微信这些入口。

也就是说，很多原来散落在不同地方的任务、消息、反馈和触发条件，现在第一次可以被接到同一个长期运行的系统里。

这个变化很重要。

因为营销工作本来就不是在一个后台里完成的。

线索在群里，反馈在邮件里，讨论在协作工具里，竞品动态在社交平台上，实验结果又可能在表格和脚本里。

如果 agent 只能“一次打开、一次运行、一次结束”，它就很难接住这些跨入口、跨时段、跨环节的动作。

OpenClaw 的意义，就是让 agent 不再只是一个“你临时调用一下的工具”，而开始像一个常驻系统一样工作。

05 autoresearch 补上的，是“自动测试”这一层

在 OpenClaw 之外，autoresearch 这条线更值得看的，是它把“测试”本身也变成了一条可运行的流程。

之前我有篇分享Karpathy 访谈文章：Karpathy 最新访谈：AI 不是在帮你写代码，它在逼你换一种工作方式

里面 Karpathy 讲 autoresearch 时，说得很直接：

让 AI 自己改代码、跑训练、检查结果、决定保留还是丢弃，再继续下一轮。

openclaw-autoresearch 就是这样的逻辑：改代码，跑 benchmark，看结果，决定继续还是放弃，整套循环会一直自动跑下去。

你把这套逻辑翻译成 marketing 语言，就特别好懂了：

• 不是帮你写一版文案，而是写完以后继续看数据；
• 不是给你做一张图，而是先拿去小流量测试；
• 不是只做一次投放，而是根据反馈决定要继续放大、换素材，还是干脆换方向。

这就是它真正厉害的地方：

不是帮你干一件事，而是替你跑一轮又一轮的测试和试错，然后给出“最优解”。

06 这波 AI 真正改写的，是营销的优化方式

所以，这篇文章真正要写的，不是“AI 很能干”，也不是“40 个 agent 很震撼”。

是营销这件事，开始多出了一层。

以前很多优化动作，不是没人想到，而是做不过来：

• 一个落地页，理论上应该不断测标题、测首图、测按钮；
• 一组广告，理论上应该先小流量测试，再筛选放大；
• 一次推送，理论上应该拆人群、拆时段、拆内容。

但现实里，大多数团队能做一轮就不错了，更多时候只能凭经验拍一个版本上线。

现在，AI agent 做的就是这些原来最难长期坚持、但又最影响结果的动作。

所以：

Relay 这类案例，让人看到营销这个工作本身可以怎么用 agent 拆和执行；

OpenClaw + autoresearch，则把这件事再往前推了一步：持续执行、持续测试、持续筛选、持续调优。

说到底，marketing 这件事，正在从人工执行慢慢变成一套24小时再跑的系统。

职场精英的婚恋痛点正在被AI重新定义。这款基于职场平台真实数据的AI红娘智能体，通过六大脑机模块构建全链路自动化服务，从精准匹配到情感引导，彻底改变传统婚恋平台的信息不对称与效率低下问题。本文将深度解析如何用AI重构婚恋匹配逻辑，打造职场精英专属的智能婚恋解决方案。

一、方案总述

1.1 需求背景

本产品为「基于职场应用平台真实数据的AI红娘智能体」，依托职场应用平台海量职场应用人身份、职业、薪资、地域、公司氛围等核心数据，以“AI自动化+人工辅助”为模式，为职场应用人群提供高可信度、高匹配度、低成本的婚恋红娘服务，区别于普通交友平台，聚焦“职场应用精英婚恋”，打造“真实、高效、安全、贴心”的智能婚恋解决方案，成为职场应用创新业务的核心增长极。

1.2 核心目标

1. 用户目标：解决职场应用人“没时间、没渠道、不信任”的婚恋痛点，提升匹配准确率、聊天开启率、线下见面率及婚恋成功率。
2. 商业目标：依托AI Agent降低人工红娘服务成本，开辟新的商业化路径，提升平台用户粘性与付费转化，打造职场应用婚恋细分领域壁垒。
3. 产品目标：构建“全链路AI自动化红娘服务”，实现从用户画像构建、智能匹配、对话引导、流程推进到风控审核的闭环，形成“AI为主、人工为辅”的高效服务模式。

1.3 目标用户

核心目标用户聚焦职场应用平台核心人群，精准定位3类职场应用人，兼顾需求强度与付费意愿：

• 核心人群：25-35岁职场应用精英（本科及以上学历，有稳定工作，月收入8k+），工作繁忙、社交圈狭窄，追求高效、靠谱的婚恋匹配，重视伴侣的职业素养与价值观契合。
• 次要人群：22-24岁应届生/职场应用新人，有婚恋需求，希望通过职场应用维度筛选伴侣，注重性价比与便捷性。
• 潜在人群：36-40岁职场应用中层，有高端婚恋需求，愿意为精准匹配、优质服务付费，重视隐私保护与服务专业性。

1.4 核心差异化优势

• 数据壁垒：依托职场应用平台独家职场应用数据（真实职业、薪资、公司、学历等），构建高可信度用户画像，解决传统婚恋平台“身份造假、信息不实”的核心痛点。
• AI全链路自动化：替代传统人工红娘80%的重复性工作（匹配、破冰、话题引导、进度推进），降低服务成本，实现规模化服务。
• 职场应用场景契合：聚焦职场应用人群需求，匹配维度兼顾职业兼容性（行业、工作节奏、薪资水平）与情感契合度（价值观、生活习惯），提升匹配成功率。
• 混合服务模式：AI负责标准化流程，人工红娘聚焦高难度场景（情感疏导、矛盾调解、高端定制），兼顾效率与温度。

二、核心产品设计

2.1 AI红娘Agent核心能力拆解

AI红娘Agent并非单一聊天机器人，而是由6大核心智能体模块组成，实现全链路自动化服务，各模块协同运作，覆盖婚恋全流程：

2.1.1 用户画像构建Agent（基础模块）

核心功能：基于职场应用平台现有数据+用户补充信息，构建精准、立体的婚恋用户画像，为后续匹配提供核心依据，无需用户手动填写大量信息，提升体验。

• 数据采集：自动同步职场应用平台用户职场应用数据（职业、公司、薪资范围、工作年限、行业、地域），减少用户输入成本。
• 画像完善：通过轻量化对话引导用户补充婚恋相关信息（年龄、学历、身高、择偶偏好、生活习惯、情感诉求），采用“分步引导”模式，避免信息过载。
• 画像标签化：自动生成多维度标签（职业标签、性格标签、择偶偏好标签、生活方式标签），例如“互联网产品经理、性格温和、希望伴侣同行业、不接受异地”。
• 画像迭代：根据用户互动行为、匹配反馈、聊天偏好，实时优化用户画像，提升匹配精准度。

2.1.2 智能匹配Agent（核心模块）

核心功能：基于双方用户画像，结合匹配算法，实现“双向精准匹配”，区别于传统“单向推荐”，提升匹配成功率与用户接受度。

匹配维度：构建“三维匹配模型”，兼顾硬性条件、情感契合、职场应用兼容，具体包括：

• 硬性条件匹配：年龄、学历、身高、地域、薪资范围等用户明确要求的筛选条件。
• 情感契合匹配：性格、价值观、生活习惯、情感诉求等隐性维度，通过用户对话、偏好反馈挖掘。
• 职场应用兼容匹配：行业、工作节奏、加班情况、职业发展规划，避免因职场应用差异导致的矛盾。
• 匹配策略：采用“精准匹配+梯度推荐”模式，优先推荐匹配度80%以上的用户，同时推送少量70-80%匹配度的用户，兼顾精准性与选择多样性。
• 匹配理由生成：为每一组匹配推荐，自动生成清晰的匹配理由（突出双方契合点），例如“你们同为互联网行业，都喜欢健身，且薪资水平相当，职场应用节奏匹配”，提升用户接受度。
• 匹配反馈优化：根据用户对推荐对象的接受/拒绝反馈，迭代匹配算法，调整匹配权重，越用越精准。

2.1.3 对话红娘Agent（交互模块）

核心功能：替代人工红娘的“聊天引导”工作，实现主动破冰、话题引导、情感支持，避免尬聊、冷场，推动双方沟通深入，降低用户社交压力。

1. 主动破冰：匹配成功后，AI自动发起对话，结合双方画像生成个性化破冰话术，避免“你好”“在吗”等无效开场，例如“Hi，我是AI红娘小X，帮你牵线了同是产品经理的XX，你们都喜欢爬山，平时休息会去户外吗？”。
2. 话题引导：实时分析双方聊天内容，当出现冷场、话题跑偏时，自动生成相关话题，引导双方深入交流（结合职场应用、生活、兴趣等维度）。
3. 情感支持：当用户出现情绪低落、聊天受挫时，提供情感疏导，例如“别着急，刚开始聊天难免有点拘谨，你们可以从共同的职场应用话题聊起，比如最近的项目难点~”。
4. 聊天规范引导：规避低俗、违规、不礼貌言论，当出现不当言论时，自动提醒并引导规范聊天，保障沟通环境。

2.1.4 流程推进Agent（关键模块）

核心功能：负责婚恋全流程的进度管理，从匹配成功、聊天沟通，到邀约、线下见面，全程自动化推进，减少用户手动操作，提升流程效率。

1. 进度跟踪：实时跟踪双方沟通进度，标记“待沟通、沟通中、待邀约、已邀约、待见面、已见面”等状态，同步给双方用户。
2. 邀约引导：当双方聊天达到一定热度（AI判断沟通顺畅、有进一步意愿），自动引导一方发起邀约，生成邀约话术，提供邀约场景建议（咖啡、餐厅、户外等）。
3. 见面提醒：邀约成功后，自动发送见面提醒（时间、地点、注意事项），提前1小时再次提醒，避免遗漏。
4. 见面反馈：线下见面后，引导双方反馈见面感受，根据反馈判断是否继续推进，或调整匹配策略。

2.1.5 信任与风控Agent（保障模块）

核心功能：依托职场应用平台的身份核验能力，构建全流程风控体系，解决婚恋场景“身份造假、骗婚、杀猪盘”等风险，保障用户安全与信任。

• 身份核验：自动关联职场应用平台的职场应用身份核验（公司任职信息、学历信息），支持实人认证（人脸识别）、手机号认证，确保用户身份真实。
• 风险识别：通过AI算法识别异常行为（频繁更换择偶偏好、索要钱财、引导线下转账、恶意骚扰），及时发出预警，暂停服务并提醒用户。
• 隐私保护：用户隐私信息（薪资、具体公司、联系方式）加密处理，聊天过程中不泄露敏感信息，双方同意后才可交换联系方式。
• 违规处理：建立违规举报机制，用户举报后，AI快速审核，对违规用户采取警告、限制服务、封号等措施，保障平台环境。

2.1.6 增值服务Agent（商业化模块）

核心功能：为有更高需求的用户提供增值服务，提升商业化转化，同时增强用户体验，具体包括：

• 聊天技巧建议：根据用户聊天内容，自动提供聊天技巧、话术优化建议，帮助用户提升沟通效率。
• 形象提升建议：结合用户职业、性格，提供穿搭、妆容、拍照建议，优化用户个人展示页面。
• 约会攻略：根据双方兴趣、地域，推荐约会地点、约会流程，提供约会注意事项。
• 情感咨询：对接人工情感顾问，为用户提供情感问题解答、矛盾调解等服务（付费增值）。

2.2 核心流程设计（用户全链路）

以用户视角，设计简洁、高效的全链路流程，减少用户操作成本，实现“一键开启，AI全程服务”：

第一步：开启服务（1分钟完成）

1. 用户在职场应用APP内点击“AI红娘”入口，同意服务协议，授权平台使用职场应用数据。
2. AI红娘Agent自动同步用户职场应用数据，通过3-5个轻量化问题，补充婚恋偏好（如“你希望伴侣的行业范围？”“是否接受异地？”）。
3. 生成个人婚恋画像，用户可查看、编辑，确认后开启匹配服务。

第二步：智能匹配（自动化）

1. AI匹配Agent根据用户画像，实时筛选匹配对象，每日推送3-5个精准匹配推荐。
2. 用户查看匹配对象详情（职场应用信息、婚恋偏好、匹配理由），可选择“接受”“拒绝”“收藏”。
3. 双方均“接受”匹配，则匹配成功，进入聊天环节；单方接受则暂不推进，保留匹配记录。

第三步：AI引导聊天（自动化+人工辅助）

1. 匹配成功后，AI对话Agent自动发起破冰对话，引导双方交流。
2. 聊天过程中，AI实时引导话题、规避违规言论，提供聊天建议。
3. 若聊天出现冷场、矛盾，AI尝试调解；调解无效则触发人工红娘介入（付费用户优先）。

第四步：流程推进（自动化）

1. AI流程推进Agent跟踪聊天进度，当判断双方有进一步意愿时，引导邀约。
2. 用户发起邀约后，AI自动通知对方，生成邀约详情，提醒双方确认。
3. 邀约成功后，AI发送见面提醒、约会攻略；见面后，引导双方反馈感受。

第五步：后续跟进（自动化+人工辅助）

1. 若双方见面后反馈良好，AI继续引导深入交往，提供情感支持、相处建议。
2. 若反馈不佳，AI调整匹配策略，重新推送更契合的对象。
3. 若双方确定交往，AI标记“交往中”，暂停匹配服务；若分手，可重新开启匹配。

2.3 状态机设计

为确保流程顺畅、可追溯，设计三大状态体系，覆盖用户、Agent、匹配结果全维度：

2.3.1 用户侧状态（核心）

• 待开启红娘服务：用户未授权、未完善婚恋画像，未开启匹配。
• 婚恋画像完善中：已授权，正在补充婚恋偏好信息，未生成完整画像。
• 匹配中：画像完善，AI正在筛选匹配对象，或等待用户查看匹配推荐。
• 待沟通：匹配成功，双方未开始聊天，AI待发起破冰对话。
• 沟通中：双方正在聊天，AI实时引导、跟踪进度。
• 待邀约：聊天达到一定热度，AI待引导邀约，或一方已发起邀约、等待对方确认。
• 已邀约/待见面：双方确认邀约，等待线下见面。
• 已见面：双方完成线下见面，待反馈感受。
• 交往中：双方见面后反馈良好，确定交往，暂停匹配服务。
• 服务结束：双方成功婚恋、主动终止服务，或服务期限到期。
• 拉黑/终止服务：用户拉黑对方，或因违规、风险行为被终止服务。

2.3.2 AI Agent执行状态

• 等待用户输入：等待用户完善画像、确认匹配、回复聊天等操作。
• 画像构建中：正在采集、整理用户数据，生成婚恋画像。
• 匹配计算中：正在根据用户画像，筛选、计算匹配对象。
• 破冰对话中：匹配成功后，正在发起破冰对话、引导双方交流。
• 话题引导中：双方聊天过程中，正在实时引导话题、规避冷场。
• 邀约推进中：正在引导用户发起邀约、确认邀约细节。
• 风险检测中：实时监测用户行为、聊天内容，识别违规、风险行为。
• 人工介入中：AI无法处理的场景（情感矛盾、复杂需求），已触发人工红娘介入。

2.3.3 匹配结果状态

• 待匹配：用户已开启服务，AI未完成匹配筛选。
• 匹配成功待确认：AI筛选出匹配对象，等待用户查看、确认。
• 双向有意向：双方均接受匹配，进入聊天环节。
• 单向有意向：仅一方接受匹配，暂不推进，保留匹配记录。
• 匹配失败：双方均拒绝，或一方拒绝、另一方未回应，匹配终止。
• 沟通停滞：双方聊天超过24小时无互动，AI将重新引导或终止该次匹配。
• 邀约失败：一方发起邀约，另一方拒绝，或邀约后未按时见面。
• 成功见面：双方按约定完成线下见面。

2.4 界面设计核心原则

• 简洁高效：避免复杂操作，核心功能（开启服务、查看匹配、聊天）一键可达，适配职场应用人“碎片化时间”使用场景。
• 信任导向：突出“真实职场应用数据”“身份核验”标识，增强用户信任感，例如匹配对象页面标注“已通过职场应用身份核验”。
• 情感温度：界面色调以温暖、柔和为主（浅粉色、米白色），搭配AI红娘拟人化形象，降低用户社交压力。
• 信息清晰：匹配理由、聊天引导、进度提示清晰明了，让用户快速了解当前状态与下一步操作。

三、技术架构设计

无需深入技术细节，重点说明“AI Agent如何实现全链路自动化”，体现产品与技术的协同性：

基础层：依托职场应用平台现有用户数据（职场应用数据、用户行为数据）、实人认证系统，为AI Agent提供数据支撑与安全保障。

核心层（AI Agent引擎）：

• 意图理解模块：识别用户输入、聊天内容、反馈信息，明确用户需求与意图。
• 用户画像引擎：基于多维度数据，构建、迭代用户婚恋画像，生成标签体系。
• 匹配算法引擎：基于三维匹配模型，实现精准匹配，实时优化匹配权重。
• 对话管理（DM）模块：管理聊天流程，生成破冰、话题引导、邀约等话术，保障对话流畅。
• 任务规划（Planning）模块：规划AI Agent的执行步骤，实现流程自动化推进。
• 工具调用模块：调用实人认证、消息推送、支付等工具，完成全链路服务。

应用层：AI红娘Agent的6大核心模块（画像构建、智能匹配、对话引导、流程推进、风控、增值服务），协同实现全流程自动化服务。

交互层：职场应用APP内的AI红娘入口、匹配页面、聊天页面、个人中心等页面，为用户提供交互入口。

四、商业化设计（仅作参考）

基于“免费引流+付费增值”的模式，兼顾用户体验与商业收益，依托AI Agent降低成本，提升付费转化，具体设计3类商业化路径：

4.1 会员订阅（核心商业化）

以下仅作参考，会员可以分为普通会员、高级会员、尊享会员，差异化提供服务，满足不同用户需求：

4.2 单次付费服务（补充商业化）

针对未开通会员的用户，提供单次付费服务，降低付费门槛，提升转化：

• 精准匹配次数：9.9元/5次，用户可购买额外的匹配次数，查看更多匹配对象。
• 人工红娘介入：49.9元/次，用户遇到聊天矛盾、情感问题时，可单次购买人工红娘服务。
• 增值服务单次购买：29.9元/次（形象提升建议、约会攻略定制）。

4.3 企业团单（潜在商业化）

依托职场应用平台的企业资源，推出企业团单服务，作为企业员工福利，拓展B端收入：

• 企业套餐：按员工人数定价，为企业员工提供免费普通会员服务、专属匹配专场。
• 企业定制：为大型企业定制专属AI红娘服务，结合企业员工特点，优化匹配算法，提升员工婚恋成功率。

4.4 商业化目标（阶段性）

• 初期（1-3个月）：完成产品上线，积累种子用户，付费转化率达到5%。
• 中期（4-6个月）：优化AI算法与服务体验，付费用户突破10万，月营收突破500万。
• 长期（7-12个月）：占据职场应用婚恋细分领域头部地位，拓展企业团单，月营收突破1000万，形成“AI红娘+人工服务”的成熟商业模式。

五、风险与合规设计

婚恋场景涉及隐私、合规、安全等多个风险点，结合AI Agent特性，设计全方位风险防控体系：

5.1 隐私风险防控

• 数据采集合规：明确告知用户数据使用范围，仅采集婚恋相关必要数据，用户可随时查看、删除、撤回授权。
• 隐私加密：用户敏感信息（薪资、具体公司、联系方式）采用加密存储，聊天过程中不泄露，双方同意后才可交换联系方式。
• 数据安全：建立数据安全防护体系，防止数据泄露、篡改，符合《个人信息保护法》要求。

5.2 合规风险防控

• 用户资质审核：严格审核用户身份，禁止未成年人使用服务，杜绝虚假身份、违规用户。
• 内容合规：AI Agent实时审核聊天内容，规避低俗、违规、违法言论，禁止传播不良信息。
• 服务合规：明确服务协议，界定平台、用户、AI Agent的权利义务，避免法律纠纷。

5.3 安全风险防控

• 防骗防控：AI算法识别“杀猪盘”“骗婚”等异常行为（频繁索要钱财、引导线下转账），及时预警、暂停服务，提醒用户。
• 骚扰防控：建立用户举报机制，对恶意骚扰、辱骂等行为，采取警告、限制服务、封号等措施。
• 见面安全：提供见面安全建议（选择公共场所、告知亲友、共享位置），提醒用户注意人身、财产安全。

六、运营策略简述

6.1 冷启动策略

• 种子用户招募：从职场应用平台筛选优质职场应用用户（高学历、稳定工作），提供免费3个月高级会员，邀请体验产品，收集反馈。
• 内容运营：在职场应用APP、微信公众号、视频号，发布职场应用婚恋相关内容（匹配成功案例、聊天技巧、情感干货），吸引目标用户。
• 邀请有礼：老用户邀请新用户开启服务，双方均可获得匹配次数、会员时长奖励，快速扩大用户规模。

6.2 用户留存策略

• 个性化运营：根据用户画像、匹配反馈，推送个性化内容（匹配对象、聊天建议、情感干货），提升用户活跃度。
• 进度激励：用户完成画像完善、聊天、邀约、见面等操作，给予积分、会员时长奖励，鼓励用户持续使用。
• 社群运营：建立职场应用婚恋社群，邀请用户加入，开展线上互动、线下活动（相亲会、职场应用联谊），增强用户粘性。

6.3 品牌推广策略

• 平台联动：依托职场应用APP现有流量，在首页、个人中心设置AI红娘入口，进行站内推广。
• 跨界合作：与职场应用类APP、公众号、企业合作，开展联合推广，精准触达职场应用人群。
• 口碑传播：重点宣传“真实职场应用数据”“AI精准匹配”“成功案例”，打造职场应用婚恋标杆，通过用户口碑传播扩大影响力。

七、产品迭代规划

采用“快速迭代、小步快跑”的模式，分3个阶段推进产品落地，持续优化体验：

7.1 第一阶段（1-2个月）：MVP版本上线

• 核心目标：完成核心功能落地，验证产品可行性，收集用户反馈。
• 上线功能：用户画像构建、基础智能匹配、AI破冰聊天、基础风控、普通会员订阅。
• 重点工作：完成AI Agent核心模块开发，对接职场应用平台数据，进行小范围测试，优化匹配算法与聊天话术。

7.2 第二阶段（3-4个月）：功能优化与商业化落地

• 核心目标：优化产品体验，提升匹配准确率与用户活跃度，推进商业化转化。
• 优化功能：迭代匹配算法（提升精准度）、完善AI对话引导（减少冷场）、新增增值服务（聊天技巧、约会攻略）。
• 商业化落地：上线高级会员、单次付费服务，开展运营活动，提升付费转化率。

7.3 第三阶段（5-6个月）：功能完善与规模化推广

• 核心目标：完善全链路服务，拓展企业团单，扩大用户规模，形成品牌优势。
• 完善功能：上线尊享会员、人工红娘介入、企业团单服务，优化风控体系，提升隐私保护能力。
• 规模化推广：开展跨界合作、线下活动，扩大品牌影响力，实现用户与营收的快速增长。

2026年开年，OpenClaw创造了一个堪称魔幻的现象：GitHub上线百余天斩获近30万星标，超越React成为史上增速最快的开源项目；腾讯大厦楼下近千人排队免费装机；闲鱼上远程代装服务标价300-800元；深圳龙岗区连夜推出”龙虾十条”补贴政策；阿里云、腾讯云、字节、百度、小米、华为等13家大厂密集跟进。

如果你是一个产品经理，看到这些数据，你的第一反应可能是兴奋——”这就是教科书案例啊！”

但如果你再多看一层数据，你会冒冷汗：Kaspersky在早期版本中审计出512个漏洞，8个为严重级别；技能市场ClawHub上被发现1184个恶意插件，感染率12%；全球超过13.5万个实例暴露在公网上，1.5万个可被直接远程代码执行；有用户一天Token花费2820美元，收入仅230美元；大量用户“装完即吃灰”。

这不是一个安全工程师的技术报告，而是一个产品经理必须直面的灵魂拷问：当我们把系统级执行权限交给AI，我们到底在做一个怎样的产品决策？

接下来，我将从产品经理最熟悉的框架——用户需求、产品架构、用户策略、商业模式4个方面，拆解OpenClaw，提炼出一套大家都可以复用的AI产品方法论。

一、需求洞察：OpenClaw为什么能？它到底解决了什么痛点？

在批判OpenClaw之前，我们必须先承认它做对了一件极其重要的事——精准的需求洞察。

1.1 一个被长期忽视的AI用户核心需求

从23年ChatGPT爆火到25年底，AI产品的主流形态一直是”对话式”——你问一个问题，AI给一个答案。用户不满意了吗？满意。但满足了吗？没有。

对话式AI解决的是“信息获取”，但用户真正的痛点是“任务执行–谁来帮我做？”。整理邮件、同步日历、处理文件、发布内容——这些重复性劳动每天消耗大量时间，AI只能”告诉你怎么做”，不能”帮你做完”。

OpenClaw的创始人Peter Steinberger说：”各大科技公司的AI产品仍停留在对话阶段，没有一款能真正适配个人用户需求、实现本地部署的全能AI助手。”于是，一个退休程序员用两个月时间，独自做出了GitHub历史上增速最快的项目。

1.2 反思：为什么大厂没做出来？

其实现在不是技术做不到——Anthropic有Claude Code，OpenAI有Computer Use——而是大厂在产品决策上做了不同的取舍。

Anthropic的Claude Cowork选择了”可控优先”策略：在隔离沙盒中运行，用户通过授权特定文件夹赋予有限权限。这像是一位在指定办公桌上工作的专业助理——安全、可控，但能力边界被明确限定（参考下图设置方法）。

OpenClaw选择了”自由优先”策略：赋予AI系统管理员级别的权限，可以操作一切。这像是一个拿到了你家所有钥匙的全能管家——强大、灵活，但如果这个“管家”被人操控了呢？

两种策略没有绝对的对错，但它们对应着完全不同的产品后果。OpenClaw的选择让它获得了爆炸式增长，也为后来的安全灾难埋下了种子。

1.3 PM 思考：增长的”暗物质”

从产品增长的角度，OpenClaw的爆火有三个关键驱动力：

第一，体验冲击力。大量社交平台分享的”AI帮我做了*****”演示视频，比任何技术文档都有传播力。用户不需要理解什么是Agent框架，只需要看到”AI在帮我干活”。

第二，部署门槛制造的“代装经济”。安装OpenClaw需要配置Docker、Node.js、API密钥——这个门槛恰好足够高，让”帮你装”成为一门生意，反过来又成为社交传播的素材。

第三，集体情绪的裂变效应。当腾讯、阿里、字节集体下场，”不跟上就被淘汰”的焦虑开始自我强化，大众市场快速破圈。

但增长不等于价值。OpenClaw催生的“代装经济”是产品化失败的反面指标。真正的增长逻辑应该是用户装完之后还在持续使用，而不是”装完即吃灰”，即使是新年期间大家都抢着下载千问“抢奶茶”，热潮过后依旧迎来了卸载潮。

二、产品拆解：OpenClaw的设计，为什么是一个”定时炸弹”？

抛开狂欢滤镜，回归产品架构本身，OpenClaw存在四个层面的致命设计缺陷。作为产品经理，这些缺陷的本质不是”技术疏忽”，而是”产品决策失误”。

2.1 权限模型：给AI发了一张”无限额信用卡”

OpenClaw默认获取系统Root级权限，可操作所有文件、软件、数据，缺乏权限隔离与审计机制。这在产品设计中犯了一个经典错误——没有遵循”最小权限原则”。

传统AI是一个“只读API”——它给你错误答案，你最多被误导。AI Agent是一个“读写API”——它不仅会给错误答案，还会基于错误判断去删你的文件、发你的消息、泄露你的密钥。

近期人民日报等多个官方媒体已经发布“养龙虾预警”，更有网友称之为“AI时代的木马病毒”

2.2 生态治理：先发布后审核的”潘多拉魔盒”

OpenClaw的开放发布模式——先发布后审核。结果是1000多个恶意技能包被上传到官方市场，伪装成smart-email-assistant等正规名称，实际植入了信息窃取木马。

产品经理的教训：开放生态 + 高权限执行 + 无审核机制 = 给攻击者搭台唱戏。投毒的Agent技能包将影响用户的全部数字资产。

2.3 “免费开源”外衣下的吞金兽

OpenClaw本身免费开源，但默认30分钟自动唤醒一次，即使无任务也持续消耗Token。有用户测算月度仅后台待命就需约750美元，有用户首月Token账单高达2万多元。

用户无法预估使用成本，没有Token限额、消费提醒，往往收到天价账单才恍然大悟。一款让用户无法预判使用成本的产品，无论技术多先进，都不具备大众化的基础。

三、产品方法论：AI Agent的”可控优先”设计框架

基于OpenClaw的全面复盘，我提炼出一套面向AI产品经理的设计框架。核心思想只有一句话：

可控 > 智能 > 强大。

3.1 产品安全架构

第一层：权限授权

按细分任务申请权限，而非一次性授予所有权限。读邮件的任务不应该有文件系统写权限，整理文件的任务不应该有网络发送权限。每一个权限申请都应该有清晰的用户确认界面和可撤销机制，参考 Claude code。

第二层：行为可追踪

所有Agent操作必须可追溯、可回滚。对高危操作（文件删除、数据发送、代码执行）设置”人在回路”确认环节。用户能随时查看Agent正在做什么，能一键中止。

第三层：平台发布审核机制

必须建立”先审核后发布”机制。结合开发者信誉评分、社区举报等多层防御体系。OpenClaw后来开启强制扫描机制，就是亡羊补牢的典型。

第四层：成本透明

内置Token消耗仪表盘、消费限额设置、实时预警机制、任务成本预估功能。让用户在下达指令前就知道”这个任务大概要花多少钱”。

3.2 产品经理的”安全自检8问”

1. 默认权限是否最小化？用户是否必须主动授权每一项能力？
2. 高危操作是否有人工确认环节？用户能否一键中止？
3. 第三方插件是否经过安全审核才能上架？
4. Agent处理外部内容时是否防护？
5. API密钥和凭据是否加密存储？
6. Token消耗是否透明？是否有限额和预警？
7. 是否有完整的操作审计日志？是否支持回滚？
8. 产品是否有明确的场景边界？还是在宣传“万能自动化”？

四、商业模式与职业启示：AI Agent时代，产品经理的机遇在哪？

4.1 行业趋势判断

尽管安全问题严峻，OpenClaw证明的核心命题不可逆转：用户需要的不是能聊天的AI，而是能帮忙干活的AI。从”对话层”到”执行层”的范式跃迁，是AI产业的必然方向。但OpenClaw只是这个方向上的”功能机”，远非”iPhone时刻”。

4.2 商业化路径推演

OpenClaw催生的代装、教程生意是短期信息差红利，不可持续。长期来看，AI Agent的商业化将走向三条路径：个人用户的”云端托管+订阅制”（类似阿里云、腾讯云做的一键部署方案）、企业用户的”私有化部署+定制服务”（如中兴通讯解决方案）。

核心竞争壁垒不再是模型参数或功能数量，而是安全合规、产品体验、场景深度和生态治理水平。

对产品经理而言，OpenClaw的故事最深刻的教训不是技术层面的，而是产品哲学层面的：在AI Agent时代，最难的产品决策不是”给AI加什么能力”，而是”限制AI不做什么”。

给AI更多权限，产品更强大，Demo更惊艳，增长更快。但克制住”让AI能做一切”的冲动，把可控性、安全性、透明度放在第一位，才是真正负责任的产品设计。

未来能真正成功的AI Agent，一定具备四个特点：足够安全、足够简单、足够便宜、足够有用。顺序不能乱——安全是第一位的。

执行AI时代已经开始。作为产品经理，我们的使命不是让AI更强大，而是让AI更可信。

在AI Agent（智能体）向实用化迭代的过程中，“Skills”（智能体技能）是连接大模型推理能力与实际执行能力的关键核心。

不同于大模型本身的思考能力，也区别于外部工具的基础功能，Skills是一套标准化、可复用、可组合的能力单元，让AI Agent从“只会思考”升级为“能落地执行”。

一、核心定义：Skills 到底是什么？

从技术层面定义，AI Agent的Skills是挂载在智能体上，可被自主调用、自由组合、重复复用的标准化能力单元，本质是“场景最佳实践 + 所需工具”的封装，核心作用是将大模型的抽象推理规划，转化为可落地、可验证的具体操作，保障输出的稳定性与一致性。

需明确3个认知边界，避免混淆：

一是与Prompt不同，Skills可模块化管理、集成资源，支持AI自主触发，无需人工手动输入；

二是与大模型能力不同，大模型提供“思考力”，Skills提供“执行力”；

三是与外部工具不同，工具是执行载体，Skills是整合工具调用逻辑、实现多工具协同的“使用能力”。

二、核心结构：一个标准Skill 的组成的关键

为了实现“可调用、可组合、可复用”，Skills需遵循统一结构，本质是一个标准化文件夹，核心由1个必需文件和3个可选子文件夹构成，简洁且实用。

必需文件为SKILL.md，是AI识别和使用Skill的唯一入口，需包含两部分：

一是YAML前置元数据，明确技能名称（小写字母+数字+连字符，作为手动调用命令）和功能描述（明确用途与边界，避免误用）；

二是Markdown正文指令，明确执行流程、输入输出要求、注意事项与示例，确保AI精准执行。

3个可选子文件夹按需搭配：

1. references/存放参考文档，提升输出准确性；
2. scripts/存放可执行脚本，实现复杂自动化；
3. assets/存放静态资源，保障输出规范。

整体而言，Skill = 元数据 + 执行指令 + 辅助资源，如同“插件”可自由复用。

三、核心分类：3类Skills 覆盖全场景需求

根据能力层级与适用场景，Skills可分为三大类，层层递进、协同互补，覆盖从基础执行到复杂业务的全部需求。

3.1 基础通用技能

所有AI Agent的底层必备能力，无需复杂工具，聚焦基础逻辑处理，如任务规划拆解、上下文管理、反思纠错、格式转换，是复杂技能调用的基础，轻量化且可自主触发。

3.2 工具调用技能

连接AI Agent与外部工具的核心，也是目前应用最广泛的类型，集成工具调用逻辑与异常处理，可自主选择工具、传递参数，如文件处理、搜索检索、代码执行、API调用等，实现“动手做事”的核心需求。

3.3 业务垂直技能

面向特定行业的高阶复合技能，由基础技能、工具技能与行业知识封装而成，行业属性强，可沉淀专家经验，如法律类案检索、营销物料生成、预算审批校验等，助力新手快速复用专业能力。

四、实战价值：Skills 的核心作用

Skills的核心价值在于降低门槛、提升效率、沉淀经验，从个人、团队、企业三个维度实现价值落地：

1. 对个人，一键调用技能即可完成专业任务，降低专业门槛；
2. 对团队，沉淀最佳实践，实现标准化复用，提升协同效率；
3. 对企业，复用现有技能、组合新技能，降低研发成本，推动AI规模化落地。

五、进阶要点与未来趋势

自定义开发Skills需遵循三大原则：

1. 单一职责、描述精准、异常处理，确保可复用、高稳定。
2. 调用方式分为自动调用（AI自主判断）与手动调用（用户强制触发），按需选择即可；
3. 优化可从数据驱动（分析日志、修正异常）与场景适配（贴合行业需求）两个方向入手。

未来，Skills将朝着生态化、智能化、低代码化发展，技能商店将成为核心载体，技能可自主学习、智能组合，可视化开发工具将降低门槛，让更多人成为Skill开发者。

总结

Skills是AI Agent实现自主执行、标准化落地、规模化复用的核心支撑，本质是标准化的能力封装。

掌握其定义、结构、分类与进阶技巧，无论是普通用户、开发者还是企业，都能更好地借助AI能力提升效率、创造价值。

随着技能生态的完善，Skills将成为AI Agent时代的核心资产，推动AI真正融入各类工作场景。

Moltbot（原名 Clawdbot）是 2026 年 1 月突然爆火的开源个人 AI 助手项目，由 Peter Steinberger（PSPDFKit 创始人）开发。

Moltbot 是一个把 本地算力 + 大模型 Agent 自动化 玩到极致的开发者效率工具。

Moltbot 目标是让 AI 不只是给建议，而是直接完成完整工程任务。

因为 Anthropic 在 1 月 27 日发律师函称 Clawd / Clawdbot与 Claude 太像，项目在当天紧急更名为 Moltbot（脱皮龙虾之意，吉祥物是小龙虾 Molty 🦞），但功能完全一致，旧命令 clawdbot 仍然兼容。

与传统对话式大模型工具不同，它强调：

• 任务自动规划（Planning）
• 本地执行（Shell、文件系统、代码操作）
• 失败反思与自修复（Reflection Loop）

安装方法

Moltbot 的安装被设计得极为友好，即使是非开发者也能快速上手。

系统要求（不一定 Mac mini）：

• 硬件：极低，512MB-1GB RAM 即可运行。
• 环境：支持 Mac, Windows, Linux，需要安装 Node.js (pnpm) 或使用 Docker。

1、推荐安装方式（一键脚本）：

直接通过终端，执行以下命令。

macOS/Linux 系统:

curl -fsSL https://molt.bot/install.sh | bash

Windows 系统：

#PowerShell
iwr -useb https://molt.bot/install.ps1 | iex

#CMD
curl -fsSL https://molt.bot/install.cmd -o install.cmd && install.cmd && del install.cmd

这会自动安装 Node.js（≥22）并完成基本配置。

2、手动安装

需要 Node.js ≥22并完成基本配置。

使用 npm：

npm install -g moltbot@latest

或使用 pnpm：

pnpm add -g moltbot@latest

安装完成后，初始化并安装后台服务（launchd / systemd 用户服务）：

moltbot onboard --install-daemon

3、从源码安装（开发模式）

git clone https://github.com/moltbot/moltbot.git
cd moltbot
pnpm install
pnpm ui:build   # 首次运行会自动安装 UI 相关依赖
pnpm build
moltbot onboard --install-daemon

配置说明

我们推荐使用一键脚本安装。

macOS/Linux 系统:

curl -fsSL https://molt.bot/install.sh | bash

Windows 系统：

#PowerShell
iwr -useb https://molt.bot/install.ps1 | iex

#CMD
curl -fsSL https://molt.bot/install.cmd -o install.cmd && install.cmd && del install.cmd

它会完成环境检测，并且安装必要的依赖，还会启动 onboarding 流程。

安装过程中的关键配置会问你几个问题，比如端口的设置 Gateway Port，按默认的 18789 即可，Model/Auth Provider 选择 AI 供应商，国内的供应商基本都支持。

如果没有海外的账号，配置咱们国内的 Qwen、MiniMax、智谱的 API key 也是可以的。

接下来就是一些其他配置，比如 Skills、包的安装管理器，可以一路 Yes 下去。

安装完后，访问 http://127.0.0.1:18789/chat，就可以打开聊天界面让它开始工作。

比如搜索最新的科技新闻：

通过第三方云云直接安装配置

现在各大平台都已经支持这个智能体，如果不想安装在本机，可以一键部署云上Moltbot：

• 腾讯云：https://cloud.tencent.com/developer/article/2624973
• 阿里云：https://www.aliyun.com/activity/ecs/clawdbot

我们可以使用阿里云的轻量级服务器安装：https://www.aliyun.com/activity/ecs/clawdbot。

可以使用它们的镜像，一键安装：

相关链接：

• 开源地址：https://github.com/moltbot/moltbot
• 官方地址：https://www.molt.bot/

为什么最近这么火？

• 真正做到了”像JARVIS一样”：能读写文件、跑终端命令、操作浏览器、收发邮件、日历、写代码、订机票、清空收件箱……
• 本地优先 + 长期记忆：所有对话跨平台共享上下文，USER.md 和 memory/ 目录会越用越聪明
• 支持几乎所有大模型：Claude、Gemini、OpenAI、Ollama 本地模型、Pi 等
• 社区技能生态爆炸：ClawdHub 上已有 500+ 社区技能（Slack、Discord、GitHub、浏览器控制、macOS UI 自动化……）
• 安装简单像 npm install，实际能力却很 spicy （开发者原话）

其核心能力包括：

• 将自然语言目标拆解为可执行步骤
• 自动调用终端命令
• 创建与修改项目文件
• 运行代码并检测结果
• 根据报错自动修复

相比 Claude Code/OpenCode 这种代码补全工具，Moltbot 更接近一个具备执行权限的工程型智能体。

• Claude Code 与 OpenCode等 强在代码质量与理解
• Moltbot 强在自动完成整个工程流程

AI Agent是一个系统，其中LLM模型在连续、独立的循环中利用一组工具来完成给定任务。根据 Anthropic的专家的定义，Agent的核心组件是其环境（其运行位置）、工具（它可以调用的功能）以及定义其核心目标的简单系统提示。Agent自主工作，根据从其工具接收到的信息更新其决策，直到任务完成。

本文为设计Agent的决策者提供一个清晰的战略框架，以评估何时以及为何部署AI Agent，重点是如何实现价值最大化以及降低风险。

1.0 核心决策框架：何时使用 AI Agent

部署 AI Agent 是一项重要的工程资源投入，并非所有问题的合适解决方案。以下四个标准必须被视为强制性的准入机制，以确保此项投资的合理性。Agent 最适合处理既复杂又有价值的任务；绕过此严格评估将直接导致资源浪费和项目失败。

在承诺采用基于 Agent 的架构之前，团队必须根据此先决条件清单验证其用例。

1.1 任务复杂性分析

任务是否足够复杂，需要 Agent？

如果人类可以轻易规划出一个清晰的、逐步执行的流程来完成该任务，那么就不需要 Agent。在这种情况下，采用更简单、更可预测的基于工作流的方法更为合适且资源效率更高。Agent 的理想用例是最终目标明确，但实现该目标的具体路径不明确或不可预测的任务。这要求模型能够做出决策，根据新信息调整策略，并在模糊的路径中找到解决方案。

1.2 任务价值评估

任务的价值是否足以证明所需资源的投入是合理的？

Agent会比其他解决方法消耗更多的资源——包括计算资源和开发时间。因此，其部署应留给”高杠杆”的任务。高价值任务是指一旦实现自动化，能带来显著回报的任务。例如，直接产生收入的任务，或能为高技能员工节省大量时间，使他们能够专注于更高杠杆率工作的任务。

1.3 工具可行性评估

Agent 是否能够获得必要的工具和信息？

Agent 的有效性完全取决于其所获工具的质量和可用性。当经过前面的价值评估后，确定要使用Agent来解决问题时，一个不容商榷的先决条件是，必须清点并验证所有必要的工具和数据源是否能够全部提供给Agent使用。如果关键工具不可用或无法构建，则必须缩小项目范围，直到满足此条件。

1.4 错误成本与可恢复性分析

错误的成本是多少？检测和纠正错误的难易程度如何？

在决定授予 Agent 多大程度的自主权时，必须将潜在的错误风险作为核心考量。这需要仔细分析两种截然不同的情况：

• 高成本错误： 对于错误难以检测或纠正成本高昂的任务（例如，在无监督的情况下修改生产代码），完全独立的 Agent 并不适合。这些场景需要采用人为监督的方法，即由人员在关键节点审查并批准 Agent 的行动。
• 低成本错误： 对于错误易于恢复且成本不高的任务，则更适合让 Agent 独立工作。例如，网络搜索中的错误，可以通过尝试不同的查询或再次检查结果来轻松纠正。

2.0 Agent的实际使用场景示例

下图中表格内容是由 Anthropic 专家提供的几个真实案例。每个用例都展示了上述原则的组合，阐明了为何基于 Agent 的方法是战略上合理的。

理解这些成功的使用场景可以为实践奠定基础。下一节将详细阐述有效构建这些系统的指导原则。

3.0 Agent 的设计原则

构建可靠的 Agent 不仅仅是编写系统提示词；更需要塑造 Agent 的环境并引导其推理。

3.1 像 Agent 一样思考并提供启发式方法

对于开发者而言，最重要的原则是构建关于 Agent 环境与约束的心智模型。正如我们内部构建这些系统的专家经常说的：”如果人类都无法理解你设计的 Agent 应该做什么，AI 也将无法理解。”

这需要进行”概念工程”——为 Agent 提供合理的启发式方法来指导其行为，而不仅仅是僵化的文本指令。对此最有效的思维模式是将其视为管理一个”刚大学毕业的新实习生”。你必须明确说明他们应遵循的一般原则，以应对模糊性。有效的启发式方法示例包括：

• 不可逆性： 指示 Agent 避免可能导致不可逆损害的操作。这一原则对于开发 Claude Code 以保护用户环境免受意外损害至关重要。
• 停止条件： 明确告诉模型何时找到了足够好的答案，以免它不必要地持续搜索不存在的“完美”来源。
• 资源预算： 为 Agent 提供工具使用量的量化指导。例如，指示它对于简单查询应使用少于 5 次工具调用，而对于更复杂的查询，最多可使用 10 到 15 次。

3.2 战略性的工具设计与选择

工具的选择和设计至关重要。必须向 Agent 提供关于在公司上下文中为特定任务使用哪些工具的明确原则（例如，指示 Agent 默认搜索 Slack 以获取内部公司信息）。一个”好的工具”具有以下几个关键特征：

• 一个简单、准确的名称，能清晰反映其功能。
• 一个格式良好、描述清晰的说明，人类工程师能够轻松理解和使用。
• 功能区分明确，以避免混淆模型。例如，六个非常相似的搜索工具应合并为一个更强大的单一工具。

3.3 管理运营现实

Agent 比简单的工作流程更不可预测，可以理解为一个黑箱，微小提示词的更改可能会产生巨大的意外副作用。例如，让agent”找到尽可能高质量的来源”可能会导致 Agent 无限循环搜索，以至于大大浪费token。即使现在的claude已经可以提供20万token的上下文窗口，但能够很好的管理20 万token的上下文窗口仍然是处理长期运行任务的关键挑战。下面的策略有助于更好的利用上下文窗口特点并扩展 Agent 的有效记忆：

1. 压缩： 使用一个专用工具，当 Agent 接近其上下文限制时（通常在19万token左右）自动调用。该工具总结对话内容，并将一个密集的摘要传递给模型的新实例，使其能够在完整上下文的情况下继续任务。
2. 外部记忆： 允许模型将其“记忆”或中间思考写入外部文件。然后 Agent 可以根据需要参考该文件，从而有效地无限扩展其上下文窗口。
3. 子 Agent： 将特定的、上下文繁重的任务委托给专门的子 Agent。这些子 Agent 执行其任务，然后将压缩后的摘要结果返回给主导 Agent。此策略用于我们的高级研究功能，以管理复杂的多源查询，同时节省主导 Agent 的上下文窗口。

然而，这些实施原则只有在能够严格衡量其影响时才有效，这就引出了评估这一关键环节。

4.0 一种实用的评估方法

评估 Agent 性能比评估简单系统更复杂，但对于取得有意义的进展至关重要。没有系统性的评估，提示词工程就会变成代价高昂的猜测，而非工程。本节概述了一种务实的、迭代式的 Agent 性能衡量方法。

4.1 有效评估的核心原则

• 从小处着手： 不要一开始就构建一个庞大的、全自动的评估套件。一套小而一致的优质测试用例，即使最初是手动运行的，也能很好地指示更改是否在改进系统。
• 使用真实任务： 在反映其真实世界应用的任务上评估 Agent，而非任意或合成的问题。例如，编码 Agent 应在真实的工程问题上进行测试，而不仅仅是竞技编程挑战。
• 利用 LLM 作为评判者： 对于输出结构多样或不可预测的情况（如研究报告），使用另一个带有清晰、明确评分标准的大语言模型来评判 Agent 输出的质量和准确性。这比简单的字符串匹配更稳健。
• 优先进行人工评估： 最终，没有什么能完美替代人工手动测试系统。审查运行记录和观察 Agent 的行为对于深入了解其优势和劣势至关重要。

4.2 关键评估方法

下表总结了评估 Agent 性能的具体、实用方法。

持续应用这些评估方法是推动 Agent 性能迭代改进的关键。

5.0 结论与建议

成功部署 AI Agent 需要战略性、有纪律的方法。构建 Agent 的决策应基于对任务复杂性、价值、工具可行性和错误成本的四部分评估框架。一旦确定 Agent 是合适的解决方案，成功则取决于周密的实施，这需要清晰的启发式方法、精心设计的工具和稳健的评估来指导。

最终建议是采用所有产品与工程负责人熟悉的方法论：为您的 Agent 构建一个最小可行产品，并通过迭代开发周期进行改进。从一个简单的提示词和一套基础工具开始。观察系统在何处失败或行为异常，并将这些观察结果视为用户反馈。这些失败模式应为 Agent 下一迭代版本的”产品待办列表”提供信息，指导您对其提示词、工具和启发式方法进行改进。这种务实的方法——从简单开始，用真实任务进行测试，并根据观察到的行为系统地改进——是构建稳健且有价值的 AI Agent 的最有效途径。