大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



你好，我是曹犟，欢迎关注我的公众号。

在上一篇文章中三个 40 岁老程序员决定用 AI 重新出发（五）：AI 辅助的 PLG 增长探索，我分享了我们如何用 AI 辅助 PLG 增长：从客户沟通、PPT 生成、官网开发到竞品监控。而这些工作的目标，归根结底是为了把种子客户吸引进来。客户真的来了之后，我们面对的就是这个系列从一开始就在追问的，也是商业上最为本质的问题：我们的 Agent 产品，到底能不能在真实客户身上跑出比人更好的结果？

一、MVP 阶段的核心命题

这也是我们当前在 MVP 阶段最核心的工作：不断迭代 Agent 产出的营销策略，直到它在足够多样的客户上能够超过 80% 的人类专家。

而为了达到这个目标，我们自然需要不断迭代营销策略，根据每个客户的行业特征、竞争环境、当前品牌声量、已有投放数据等，快速调整策略，快速验证效果。这个“快速迭代”的需求，直接催生了这篇文章后面所要讨论的架构演进。

这篇文章里，我会分享我们在 MVP 验证阶段如何从最初的多 Agent 产品架构，逐步演化为 Skill 驱动的模式，再到引入 Harness（代码护栏）的过程。这并不是一个提前设计好的演进路线，而是被真实的问题一步步逼出来的。

二、从多 Agent GUI 到 Skill 驱动

最初的架构：多 Agent + GUI

产品最早的架构，是一个比较常规的方案：前端是一个 GUI，后端是多个 Agent 分工协作，有的负责行业研究，有的负责方案制定，有的负责执行投放，有的负责监控优化，各个 Agent 之间通过预定义的流程串联起来。除了具体推理过程交给模型之外，产品的核心骨架仍然是由 AI 生成的代码驱动的。

这个架构在技术上没什么问题，但在 MVP 阶段很快就暴露了致命的短板。

第一，策略迭代太快，GUI 跟不上。 MVP 阶段最重要的事情是验证策略有效性，这意味着我们几乎每天都在调整策略逻辑。而每次策略调整，如果还要改前端界面、改后端接口、改 Agent 之间的流程，那效率实在太低了。我们不是在做一个成熟的产品，而是在做一个高频的具有很大不确定性的实验。

第二，多 Agent 协调的开销太大。 多个 Agent 之间要传递上下文、要协商、要处理异常，调试起来非常痛苦。经常出现一个 Agent 的输出格式稍有变化，下游 Agent 就理解错了的情况。花在“让 Agent 之间正确沟通”上的时间，比花在“让 Agent 做出好策略”上的时间还多。

第三，客户等不了。 在某个种子客户验证上得到了一个新的认知，我们希望马上就能调整策略验证效果。但如果要走“改代码、测试、部署”的流程，至少得好几天。这在 AI 时代的 MVP 验证阶段是不可接受的。

我们需要一种更轻量、更灵活的方式来承载和迭代策略。

转向 Skill 驱动

解决方案其实就是我们之前在其他场景中就已经验证过的模式：Skill 驱动。

之前，我提到过我们用 Skill 来生成客户 PPT、用 Skill 来监控竞品。这些 Skill 本质上就是用自然语言写成的“操作手册”，告诉 AI 在什么情况下做什么、能用哪些工具、哪些红线不能碰、输出应该是什么格式。

我们把同样的思路应用到了产品侧。比如“广告投放方案制定”这个 Skill，里面详细描述了：先做行业研究，再做关键词分析，然后生成广告文案，最后做经济可行性验证。每一步该调用什么工具、该参考什么数据、有哪些约束条件，都写得清清楚楚。

这样一来，迭代策略就等于改一份文档，不需要改代码，不需要重新部署。相当于给一个能力很强的员工换了一本操作手册，他立刻就能按新的来执行。

如果你管理过团队，一定知道，制定 SOP 文档比写代码灵活得多。我们可以随时更新 SOP，不需要排期，不需要上线，改完马上生效。Skill 驱动，本质上就是这个思路的 AI 版本。

按照这个思路，我们开始把产品中的核心流程和策略逻辑逐步迁移到 Skill 上。

我们的 Skill 体系

一个多月迭代下来，我们的 Skill 体系已经形成了一个比较完整的框架：

每份 Skill 文档大概从 200 到 560 行不等，最复杂的客户接入流程有 9 个主步骤。

Skill 驱动的甜蜜期

转向 Skill 驱动之后，效果是立竿见影的。

不仅策略迭代速度快了很多，更重要的是，基于人类可读、可直接修改的 Skill 文档，人与人的协作、人与 AI 的协作也顺畅了很多。三个人可以同时修改不同的 Skill，彼此 Review 也很容易。你不需要慢慢读代码，直接读自然语言就能理解。策略讨论的结果，也可以立刻体现在文档修改上，不需要再经过“翻译成代码”这个环节。

这种模式非常契合我们系列文章一直在讲的 “文档驱动，AI 放大”，文档承载意图，AI 负责执行。

但甜蜜期没持续太久，新的问题很快出现了。

三、Skill 驱动的真实挑战

随着我们在真实客户上的持续迭代，策略越来越成熟，Skill 文档也越写越长、越写越详细。我们不断往里面补充：新发现的行业规律、客户反馈带来的策略调整、之前踩过的坑的防范措施等。

用自然语言驱动 AI 执行复杂业务逻辑，好处很明显，但问题也逐渐暴露出来。从我们的实践和公开资料来看，Skill 驱动面临的挑战至少包括以下几个方面。

挑战一：选择性失忆与 U 型注意力曲线

这是我们最早遇到，也是最棘手的问题。AI 开始出现“选择性失忆”。

具体来说，Skill 文档开头和结尾的指令，AI 执行得很好。但文档中段的指令，经常被忽略，或者被 AI 自由发挥成了别的东西。

例如，我们有一份“广告投放方案制定”的 Skill，其中有一步关键检查：按当前的获客成本，计算这个方案到底能不能赚钱。这是一个非常重要的“经济可行性验证”环节，如果算出来需要的转化率高得离谱，那这个方案就是数学上不可行的，应该直接终止。

这一步写在文档的中段，大约第 350 行的位置，结果 AI 直接跳过了。

输出的方案要求的转化率是实际可能值的 14.5 倍，相当于一个根本不可能完成的方案，但 AI 依然毫不犹豫地给这个方案配好了关键词、写好了广告文案，煞有介事地呈现了一份“完整的投放方案”。如果我们没有人工审核这一步，这个方案就会直接交付给客户。

类似的问题不止这一处，例如，客户接入流程中有一个技术检测步骤写在第 170 行附近，也经常被 AI 跳过。

为什么会这样：U 型注意力曲线

这个现象背后有学术研究的支撑。2023 年，斯坦福大学的 Liu 等人发表了一篇名为《Lost in the Middle》的论文，揭示了一个重要发现：大语言模型的注意力呈 U 型分布，对输入内容的开头和结尾处理得最好，对中间部分的处理则显著下降。

他们的实验数据非常直观：在一个 20 篇文档的问答任务中，当答案所在的文档放在中间位置时，准确率比放在首位或末位时下降了超过 30 个百分点。

这和人类的特点也很像。你给一个新员工一份 10 页的操作手册，他大概率容易记住第 1 页和第 10 页，但第 5 页的关键步骤却更容易遗漏。这不是他“笨”，而是注意力分布的结构性特征。也正因为如此，在设计流程和信息结构时，大家往往会把最关键的信息放在开头和结尾。

对于 AI 来说，道理也是一样的。当你的 Skill 文档膨胀到五六百行的时候，写在中间的那些规则，AI 的“注意力”天然就会打折扣。它不是“不遵守规则”，而是“看不见规则”。

我们的应对措施

发现这个问题之后，我们陆续尝试了多种应对方案，效果也各不相同。

第一，在文档开头强调红线。 在每份 Skill 文档的最开头，加一个醒目的“绝对不能违反的规则”区域，把最重要的约束条件集中声明。类似飞行员检查单上的“WARNING”，不管后面内容多复杂，这些红线必须首先被看到。实测下来，这一个简单的改动的确会让合规率明显提升。

第二，给文档“瘦身”。 之前我们最复杂的 Skill 膨胀到了 840 行。我们果断动刀，把参考资料、背景说明等“非执行性内容”拆到独立文档里，只在需要的时候按需加载。核心的 Skill 文档从 840 行砍到了 558 行。

第三，“三明治结构”。 既然 AI 对开头和结尾的注意力最好，那我们就把关键规则在开头声明一次，在结尾的检查清单里再重复一次。宁可重复，不能遗漏。同一条关键规则至少出现两次，一次是“你要做什么”，一次是“你做完了吗”。

第四，在高风险步骤设“关卡”。 那个被跳过的经济可行性验证，我们把它从“文档中段的一句话”升级成了一个独立的步骤，配上了强制验证环节。类似于在生产线上加了一道质检工序，即使工人（AI）走神了，到了这一步也必须停下来检查。

第五，我们还尝试过用代码拦截，但失败了。 设想很美好：在 AI 执行操作之前，用代码自动检查它是不是违反了某条规则。但实际操作下来发现，绝大多数规则需要“理解上下文”才能判断。比如“这个获客成本数据到底来自哪个工具？”，这不是简单的文本匹配能搞定的事情。代码拦截适合做防止误操作的“安全阀”，但不适合替代 AI 对规则的理解。

这些应对措施加在一起，效果是显著的。但它们本质上都是在“Skill 文档”这个框架内做优化，还是有它的局限性。

同时，“选择性失忆”只是 Skill 驱动面临的挑战之一。

其他挑战

还有两个我们在实践中明确感受到的问题：

非确定性。 代码跑 100 次，结果完全一样。但同一份 Skill、同样的客户数据，AI 每次执行的结果都可能有微妙差异，比如关键词的选择、广告文案的措辞、预算分配的比例。对于创意类工作，这种不确定性反而是优势。但对于需要一致性的场景，比如执行标准化的监控检查，你没法向客户解释“上次跑出来是 A 结论，这次同样的条件变成了 B 结论”。

累积漂移。 我们的 Skill 通常包含多个步骤，步骤多的可能有近十个串联在一起。前面步骤的小偏差会逐步放大：第 1 步行业分析偏了一点，第 2 步关键词选择就会跟着失准，到第 5 步生成投放方案时，可能已经完全跑偏了。代码不会漂移，但自然语言驱动的多步骤流程，天然存在这种误差传递的风险。这也是我们前面要“在高风险步骤设关卡”的另一个原因，不只是防失忆，也是在关键节点纠偏，防止误差一路累积下去。

值得一提的是，很多公开讨论中经常提到的 token 成本问题，对我们来说反而不突出。我们做的是公域营销 Agent，每一次决策都直接关联客户的营销 ROI，一个好的方案可能帮客户省下几千甚至几万美金的营销费用。相比之下，每次执行消耗的 token 费用完全可以忽略不计。在三个 40 岁老程序员决定用 AI 重新出发（二）：用 AI 写商业计划书一文中，我们讨论过三种企业预算：IT 预算、BPO 预算和营销预算。我们之所以选择切入营销预算，也正是因为这个领域的 token ROI 足够高。

至于行业里也经常讨论的安全性和可测试性问题，在我们目前的实践中还不算突出，因此这方面我们暂时也没有太多一手经验。

小结

存在这些挑战，并不代表 Skill 驱动不好，而是说明纯 Skill 驱动有它的能力边界。同时，我们也发现，我们在应对这些挑战时摸索出来的这些做法，行业里其实已经有了一个统一的名字。

四、Harness：给 AI 加上护栏

行业怎么定义 Harness

2026 年 2 月，HashiCorp 的联合创始人 Mitchell Hashimoto 在他的博客中写道，他使用 AI 编程的最高阶段，叫做“Engineer the Harness”，也就是：每次 AI 犯一个错，就把防错逻辑固化到 Harness 里，让它再也犯不了这个错。

几天之后，软件工程领域的标志性人物 Martin Fowler 发表了一篇正式文章《Harness Engineering for Coding Agent Users》，给出了更系统的定义：Harness 是 AI 模型之外的一切控制机制，包括执行环境、工具、护栏、上下文组装、输出验证。用一个公式表达就是：

Agent = Model + Harness

Fowler 进一步把 Harness 分为两类：

这么看起来，前面那些凭直觉和经验摸索出来的应对措施，原来就是所谓的 Harness。“在文档开头强调红线”是 Guides，“在高风险步骤设关卡”是 Sensors，“三明治结构”则是两者的双重保险。我们其实一直都在 Engineer the Harness，只是不知道它叫这个名字。

Big Model vs Big Harness 之争

围绕 Harness 的价值，行业内也出现了一场有趣的争论。

Big Model 派认为，模型能力的提升终将让 Harness 变得多余。OpenAI 的研究者 Noam Brown 说过一个很形象的例子：“之前人们在 GPT-4 上搭了很复杂的脚手架来增强推理能力，结果 o1 推理模型一出来，这些脚手架反而拖了后腿。”言下之意是，你今天辛苦搭建的 Harness，可能明天被一个更强的模型直接废掉。

Big Harness 派认为，Harness 才是真正的价值所在。LlamaIndex 的创始人 Jerry Liu 指出，LangChain 的 coding agent 仅仅改了 Harness、没换模型，性能就从 52.8% 提升到了 66.5%。而 Cursor 这个产品之所以能达到 500 亿美金的估值，卖的本质上就是一套精心设计的 Harness。

对于这场争论，社区里有一句吐槽我觉得很精辟：“Big Harness 的人想卖给你 Harness，Big Model 的人想卖给你模型。”两边都有道理，也都难免带着各自的利益立场。

当然，与其站队辩论，不如看我们自己的实际问题应该怎么解决。

Harness 的控制力光谱

如果把 Harness 抽象成对大模型的约束与控制，那么在我们的实践中，这些控制手段按控制力强弱可以分为三层：

越往右走，确定性越高，但灵活性也越低，毕竟改代码的成本远高于改一份文档。所以不是控制力越强越好，而是要在确定性和灵活性之间找到平衡。

我们的选择：哪些逻辑进代码，哪些逻辑留给 AI

那在我们自己的场景中，什么样的逻辑适合用代码接管，什么样的逻辑应该留给 AI？我们慢慢形成了一个比较清晰的判断标准。

适合代码接管的：

适合留给 AI 的：

简单概括：规则确定的用代码，需要判断的用自然语言。

当然，还有些通用逻辑，比如数据质量等级的判断、异常分类框架等，目前在七八个 Skill 中各自重复实现，格式和规则都一样。未来，这些逻辑是可以统一沉淀到代码层的，既减少重复，也提高一致性。

需要说明的是，代码接管对前面提到的另外两个挑战也有帮助：代码接管的环节每次执行结果完全一样，天然消除了非确定性。同时，这些环节的输出是确定的，也不会向下游传递误差，从源头减少了累积漂移的风险。

到目前为止，给 Skill 加上包括代码护栏在内的足够约束之后，我们大致找到了一个适合 MVP 阶段的平衡点：既能保持策略高频迭代所需要的灵活性，又能在关键环节拿到足够的确定性。当然，随着产品阶段的变化，这个平衡点也可能再次被打破。

五、我的观点：不必追求纯粹，解决问题就好

这个系列文章里，我们一直在强调 “文档驱动，AI 放大”。这篇文章中，这句话也有了更具体的含义：Skill 文档承载策略意图、领域知识和操作流程，Harness 保证执行质量、防止不可逆错误、提供确定性兜底。两者共同构成了一个完整的 Agent 系统，缺一不可。

当然，在我们目前的实践中，Harness 还不是万能的，但它毕竟把问题从“全靠 AI 自觉”变成了“在关键环节有兜底”。

回头看我们在 MVP 阶段走过的路，从代码驱动的多 Agent 架构，到自然语言驱动的 Skill 模式，再到 Harness 下代码与自然语言混合驱动的系统，其实就是一个不断在确定性和灵活性之间寻找平衡的过程。

随着大语言模型能力持续提升，比如有效上下文窗口更长、指令遵循能力更强，也许有一天，AI 真的能可靠地执行一份上万行的 Skill 文档，不遗漏任何一步。今天我们不得不用代码来保障的部分，到那时也许可以重新交还给自然语言。但代码的核心优势，比如确定性、可审计、低成本，并不会消失。这不是模型能力的问题，而是执行范式的根本差异。所以，“自然语言 + 代码”这种混合形态，大概率会是 AI Agent 产品的长期形态。只是随着模型进步，两者的边界会不断移动。

哲学上有一个观点让我很有感触：“概念会反过来影响人的思维。”在 MVP 迭代的过程中，我自己也会不自觉地陷入概念的纠结，这个逻辑到底“该用代码”还是“该用自然语言”？但现实世界是复杂的，是不完美的，不是非黑即白的。最终能够解决问题就好，管它载体是啥。 只是要清楚地知道，为什么选这个载体即可。