Agent 时代的复利进化全解析（非常详细）：一文读懂 Compound Engineering，看这一篇就够了！

大靠山

556人浏览 · 2026-01-09 22:05:23

大靠山 · 2026-01-09 22:05:23 发布

一、Compound Engineering：让Agent从过去的经验中成长

“Agent为啥又忘了上次学的东西？”

这是用AI Agent的人最常遇到的挫败感。上次犯的错，这次还在犯；上次教的东西，这次完全不记得；人工总结的经验，Agent看都不看。

GPT-5、Gemini 3.0 Pro、Claude 4.5等模型的推理能力本身也不弱。但实际工作中，Agent每次似乎都要从头来，每次都要重新解释context，每次都要重复同样的纠错。

原因在于：多数Agent是无状态(Stateless)的。每次调用都是全新的会话，顶多有个chat history。就像患了失忆症的天才，智商再高，但每天醒来都不记得昨天学了什么。

Every.to似乎找到一种解决方法。这是一家AI原生的media tech公司，运营着包括Chain of Thought在内的多个产品，他们的特点是极小的团队规模（比如一个工程师管理5个产品）却实现了极高的生产力。

在AI Coding方向，Every.to提出了一套叫Compound Engineering(复利式工程，CE)的方法，来解决Agent如何从过去的经验中学习的问题。一个简单的示例是：

Every.to的研究员早上到公司，打开电脑可以看到Claude自己review代码并做了Checkin：

“Changed variable naming to match pattern from PR #234，removed excessive test coverage per feedback on PR #219，added error handling similar to approved approach in PR #241.”

三个PR #219、#234和#241，里面都是过去三个月的经验。Agent这次不仅记住了，还主动应用了。

Every.to的CEO Dan Shipper和工程师Kieran Klaassen在2025年下半年提出"Compound Engeering"的理念并实践了：

“传统工程是线性的——每个功能的成本基本恒定。Compound Engineering恰恰相反：你期望每个功能让下一个功能更容易构建。因为Compound Engineering创造了学习循环：每个bug、每次insight都被文档化，并被future agents复用。”

用Kieran的话说更直白：

"We don’t write code anymore. We cultivate a system that writes code.

“我们不再写代码。我们在养一个会写代码的系统)"。

这套方法的核心观点很直白：

Agent的真正挑战首先是"如何记住上次学的东西且不再犯同样的错误"，然后才是"如何变聪明"。

Compound Engineering通过让每次工作都教Agent、每个bug转化为类别级规则、Agent自动应用学到的模式来解决这个问题。像金融里的复利：初期投入不小，但知识复合，边际成本趋近于零。Every.to用这套方法让单个工程师运营5个产品，实现了10x生产力提升。

二、什么是Compound Engineering?

2.1 编程场景的瓶颈

Every.to团队发现了一个反直觉的现象：当AI能在几分钟内生成完整功能时，开发速度并没有提升10倍。问题出在哪？

团队工程师Vinci Rufus总结了一个公式：

Productivity = (Code Velocity) × (Feedback Quality) × (Iteration Frequency)

有效性 = (行业知识) × (决策捕捉) × (经验应用)

当AI Coding的代码速度接近即时或瞬间完成时，瓶颈转移到反馈质量和迭代频率验证正确吗？提取出经验了吗？

理论上AI让开发快100倍，实际只有3-7倍。为什么？因为瓶颈不在"写代码"，在"验证+学习"。这就是为什么Kieran说他们80%的时间在规划和审查，只有20%在执行。

传统方案为什么不够？

Context Window存在上下文腐烂问题(Context Rot)，即token越多，召回效果越差；RAG只能检索不能让Agent主动学习和应用；Fine-tuning反馈循环慢(数周)且不敏捷。共同的问题是：试图让模型更聪明，而不是让系统能学习。

2.2 核心机制

Compound Engineering之所以有效，基于四个互相增强的核心机制：

机制1: 边做边教(Teach Through Work) — 知识在工作情境中产生，不是事后总结。每个决策、每个权衡、每个偏好，在做出的当下就捕获并编码。这让教AI变成工作的一部分，而不是额外负担。

机制2: 分类预防(Category-Level Prevention) — 每个失败或不符合预期的结果不是孤立事件，而是学习机会。修复bug的同时，提取底层模式，预防整个类别的问题，从"解决一个问题"到"解决一类问题"。

机制3: 活知识库(Living Knowledge Base) — 知识不是静态文档，而是持续演进的活系统。新模式不断加入，过时模式被剪枝，矛盾模式被解决。像生物演进，不是累积，是适应。

机制4: 反馈循环压缩(Feedback Loop Compression) — 不只是代码生成快，而是整个开发周期(规划 → 执行 → 审查 → 复合)的系统性压缩。并行编排、自动验证、快速迭代，让知识从发现到应用的时间从天缩短到分钟。

这四个机制互相增强：边做边教产生知识，类别级预防提取模式，活的知识库管理演进，反馈压缩让学习循环加速。结果是指数级复合而不是线性累积。

2.3 Frustration Detector案例

Kieran构建了一个挫败感检测器，自动检测用户使用过程中是否遇到挫败，生成改进报告。传统方法要几天，知识都在工程师脑子里，下次还要重来。

Compounding Engeering的思路不同。他的想法是：给Claude一个示例，然后：“This shows frustration. Write a test。” Claude写测试，失败——预期。

边做边教

让Claude写检测逻辑，但测试时不稳定，然后就不断去自我修复。这个过程的关键在于：让Claude迭代检测提示直到测试通过。不是事后总结，是边做就让Claude捕获经验。这就是边做边教。

Claude自我优化的过程大概是：调整提示 → 运行测试 → 读日志 → 再调整。第一轮10次只通过4/10。分析失败日志，优化再测试，直到通过10/10，上线。

Bug变分类预防

将这个工作流程写到Claud.md里。下次类似任务，可以直接"use prompt testing workflow"，系统在编码阶段就可以利用这些流程。这就是类别级预防：从一个问题到一类问题。

传统迭代要几天，Claude自我优化几小时。这就是反馈循环压缩。工作流写进CLAUDE.md后持续演进，这就是活的知识库。

效果: 上线时间1周+ → 1-3天。

这就是Compound Engineering：一套让系统从每次工作中学习的方法论。在编程场景，Every.to三个月验证了它。

看到这个理念，直觉这个理念不止于编程。任何需要专业知识积累的领域，都可以用类似思路。如何将它应用到行业场景呢？

三、将Compound Engeering理念应用到行业场景

3.1 通用模型落地行业场景的两道坎

通用大模型很聪明，但要真正在行业场景干活，有两道坎过不去。

第一道，Agent没有行业专业知识。

法律Agent不知道你们公司的合同审查套路，人力Agent不知道什么人能干好活，催收Agent不知道什么话对什么客户管用。模型智商超人，但领域能力就像刚毕业的新人，啥都懂一点，啥都不精。

Anthropic的Skills找到了方向。把行业知识打包成organized folders，渐进披露按需加载，不会把上下文塞爆。这解决了"如何给Agent专业知识"的问题。Skills是行业专长的打包方式。

第二道，这些知识是死的。

给Agent一个"催收话术大全"，它照着念，但不知道什么时候该用哪套。就像新人拿着系统手册，能照着做，遇到没见过的情况就懵了。

真正的专长不是背规则，是从几百上千案例里摸出来的判断力——什么情况下首先要共情？什么时候该直接点？这些判断需要从实际结果中学，不是靠背话术。

Every.to的Compound Engineering本质上就干这个。让Agent从每次工作中学习，把单个案例提炼成模式，模式持续优化，所以他们工程师为什么说"我们在养一个会写代码的系统。" 不只是重复地用Agent，更要想办法让它演进。Compound Engeering是领域能力演进的引擎。

当Compund Engeering碰到Claude Skills会发生什么？

最近，有个哥们Jeffery Kaneda在X上发了个帖子：

“Capture task structure as Skill，then compound it. Skills compose. Ten Skills don’t give you 10x—they give you 100x。”

他说的是编程场景，compound-engineering-plugin里有skills，业界已经有一帮人在实践了。

但我看到这个时，第一反应：这个组合在行业场景可能更猛。

为什么？编程的模式最终会趋同，社区会分享，大家殊途同归。但行业场景不一样——你的客户群、你的招聘数据、你的催收结果，你的业务决策逻辑，这些是独有的。如果让行业Skills不只是静态知识，而是从你的专有结果数据中持续演进？

那不只是"Agent有专长"，是"Agent的专长在复合"。护城河别人没法复制——可以抄你的Skills结构，但抄不了你6-12个月积累的模式。

具体怎么搞？

编程场景有初步实践了，但行业的实践公开看到的还不多。以下是我们基于Compound Engeering理念、Every.to的实践，结合行业场景Agent的特点来尝试做个组合式设计探索。

3.2 行业场景的不同挑战

有效性 = (行业知识) × (决策捕捉) × (经验应用)

即使Agent有了足够的行业知识，真正瓶颈仍在于：能否从业务流程或具体案例中捕捉到决策的核心逻辑？能否在新案例中主动应用学到的决策经验？

行业场景和编程本质上不同。如图所示，行业场景的价值可能更大，原因有三：

第一，知识(Knowledge)更专有。 编程的最佳实践是公开的。而行业场景里，每家公司的合同审查清单、诊断协议、风控逻辑——这些是公司特有的。很多公司尝试用Skills教Agents企业业务实践和the weird and unique ways they use bespoke internal software。" 那些"weird and unique"才是真正竞争优势。

第二，专长(Expertise)形成更慢。 开发者从初级到高级约2-3年。对行业专家，初级律师到独立审合同5-10年，医学生到主治医师8-12年，新招聘官到准确判断候选人也得3-5年。

第三，护城河更深。 编程模式会趋同到行业最佳实践。但你的客户投诉结果数据、ICU协议、销售转化模式——独有的。竞争对手即使用同样LLM，无法复制你6-12个月积累的专长。

Snowflake CEO提出的一个观点个人比较认可：“Continuous learning companies will gain compounding advantages。” 不是谁有最佳模型(99.999%的公司都不需要，也训不起LLM)，而是谁能够围绕LLM构建起最佳学习循环。

3.3 Skills + Compound Engineering的结合

3.3.1 核心突破：从知识到专长

之前写过一篇利用Skills提升大模型Domain-Specific能力，但仅有Skills还不够。你给Agent"催收话术大全"，但Agent会机械应用，缺判断。需要突破的是借鉴Compound Engeering理念让Skills从静态知识(Knowledge)变成持续演进Expertise的能力。

知识(Knowledge)和专长(Expertise)的本质区别在哪？

知识是"知道"：知道empathy-first是策略，知道高价值客户需要不同对待，知道有升级标准。专长是"知道何时和如何"：什么情况下empathy-first最有效？如何识别客户实际是高价值？升级的时机如何影响结果？这些判断来自积累的经验的模式识别。传统靠人类专家多年试错，Compound做法是从结构化结果数据系统性提取。

Result-driven演进的机制很关键。为什么记录 context + strategy + outcome 三元组？记录模式决定能提取什么模式。上下文不能太粗也不能太细，捕获决策相关的关键变量。策略要明确记录用了哪个模式，建立因果关系。结果不只二元，包括结果、置信度、次要指标。这些都让模式提取从"经验直觉"变"数据驱动"。

模式提取的统计学考量：为什么每周需要至少批量30-50个案例？30是最小样本量，但更重要的是效应量。假设empathy-first对高价值成功率78%，直接45%，差异33%是大效应。10个样本？标准误差太大，是噪音。30-50对大效应(>20%)足够，对小效应(<10%)可能错过。

权衡之下，更现实的做法是宁可错过小效应，保证快速反馈。从效果要求看，置信度评分>0.8时才提升到Skills，定期重新评估，不够就及时删除，重点在"足够快的反馈和迭代"。

为什么比RAG/Fine-tuning优？

RAG检索让Agent读细节再重新分析，每次从头推理，token多、延迟高、不稳定。Skills直接给模式，Agent直接应用，token少、延迟低、一致性好。打个比方，RAG像"每次翻病历重判"，Skills像"诊疗指南直接用"。

Fine-tuning是模型级，需重新训练，几周反馈，敏捷性不够，关键还贵。Skills是系统级，更新文件，分钟级，今天发现明天应用，成本也更低。

3.3.2 三层进化路径

Layer 1: 静态Skills — Agent有知识，缺判断。像新人：知道规则，不知何时打破。

Layer 2: 自适应Skills — 第一个质变，从"执行"到"应用判断"。

结果记录创造因果图：上下文 → 策略 → 结果。构建 P(Outcome | Context, Strategy)，这是条件概率，是判断的量化形式。

模式提取：观察 → 统计模式 → 规则。聚个例子，45个观察(高价值 + empathy → 0.78) → 模式 → 规则: IF 高价值 THEN empathy_first (置信度0.82, n=45)。

Layer 3: 集体Skills — 从个人到组织。

5个律师各100个案例 = 500个案例。每个人单打独斗，从100个案例里学。如果5个律师间共享，大家整体从500个案例里学，5倍优势。

但更重要的是多样性：诉讼和并购团队不同，不同律师的判断提供反事实学习。“团队A说必须有，团队B谈判掉了”——多样性让模式更稳健。

看到有一些小团队把每个人的经验不断汇总到一个统一的Claude.md/Agent.md文件，以把团队的智慧告诉LLM。团队知识复合需要每个人参与，一个人不参与就可能会有一个盲点。

多样化、高质量地持续演进，拉长周期就会有时间的复利。即使用同样的模型，甚至差不多的行业数据，但团队特有的Compound Engeering + Skills组合是独特的护城河。

3.3.3 "Compound Engeering + Skills"设计案例推演1 - 催收系统

传统催收靠固定话术碰运气。核心问题是：什么策略对什么客户有效？如何从每次催收中学习并持续优化？

三个关键演进：客户细分、结果定义、策略升级

1. 客户细分：从粗糙到精准

第1个月，按金额和逾期天数简单分类。很快发现：同样欠5000块逾期30天的客户，有的是暂时困难，有的是故意拖延，需要完全不同的应对方式。

第3个月，100个案例后，数据告诉我们需要加两个维度：

沟通响应性：接电话还是躲着？
困难指标：主动提到困难还是闭口不谈？

关键发现来自数据："响应+提困难+高价值"的客户，用共情策略成功率82%；"回避+不提困难"的客户，直接施压反而67%有效。

这些细分规则不是专家拍脑袋，是从实际结果中"长"出来的。

2. 结果定义：不只看收回钱

什么算成功？不能只看"要回钱了"这么粗糙。

设计多层评估：即时效果（客户态度）、7天跟进（承诺兑现率）、30天解决（实际回款）、次要指标（客户满意度、关系维护）。

为什么要这么复杂？因为催收不只是"这次收回钱"，还要"下次还能催"。短期过于激进，客户信任崩了，长期更难办。

3. 策略升级：从规则到判断

第1个月：用行业通用话术，有效但不够好
第3个月：针对不同细分用不同规则，效果提升
第6个月：开始有情境判断——“这个客户虽然回避，按规则该用共情，但这次可能得直接点”

从规则到判断这一跳，需要1000+案例的积累，更需要人类专家在边缘情况时教AI：“数据说A，但我判断这次该用B，因为…”

这就是Human-in-the-loop的关键作用：不是微观管理每个决策，而是在AI拿不准的边缘案例教它判断逻辑。

三层护城河，别人抄不走

细分规则来自你的客户群；结果定义反映你的业务优先级；判断经验是团队集体智慧。三者结合，形成数据+方法论+专长的复合。竞争对手可以学你的框架，但复制不了6-12个月积累的模式。时间就是护城河。

3.3.4 "Compound Engeering + Skills"设计案例推演2 - HR招聘系统

催收和招聘都是行业场景，但有个根本区别：结果出来的时间。催收打完电话马上知道结果，招聘呢？得等3个月、6个月、甚至12个月才能看出来这人到底行不行。

等不起的反馈循环

催收系统可以每周提取模式，招聘没这么快。得等：3个月看看人适不适应，6个月看看业绩走向，12个月才能下定论。

而且代价还高——招错一个人，公司损失至少5万美元（薪水+培训+机会成本）。

所以设计得分层：3个月的信号，只能做小调整；6个月看趋势，但不敢动太多；12个月数据够了，才敢大改招聘标准。

真正有用的招聘信号是什么？

一开始，我们用常规指标判断候选人：技术过不过关？文化合不合？学历背景？面试表现？

12个月后回头一看，发现一个有趣的现象：有副项目的人，平均绩效8.2分；没有副项目的人，平均7.1分。

但这不能直接说"业余项目很重要"，因为这只是相关性，不是因果。

什么意思？可能不是"“业余项目让他们优秀，而是"优秀的人本来就爱做业余项目”。

怎么找真正的因果？

我们用反事实推理：找两组人，除了"有没有副项目"，其他条件都差不多（比如都是同样的学历、同样的工作经验、同样的技术水平）。

对比结果：

有业余项目的这组：8.2分
没业余项目但其他都相似的那组：7.1分
差值1.1分 = 这就是"业余项目"本身带来的效果

但更重要的发现是：副项目不是直接让人更厉害，而是它反映了两个底层能力——学习速度快和自驱力强。

对初创公司来说，这两个特质比"现在会什么技术"更关键。因为初创变化快，今天学的明天可能就过时了，但学得快、自己能推动自己的人，永远能跟上。

慢但深的护城河

催收系统可以快速试错，招聘不行，必须谨慎。但这也意味着：招聘的复合更慢，但护城河更深。

竞争对手想快速积累100+个有效的招聘案例？至少得1年吧。先行者的时间优势会不断复合。

四、几点思考

首先：Agent的问题根本不在模型是不是足够聪明。

你看现在的模型，GPT-5、Claude 4.5、Gemini 3.0 Pro，推理能力一个比一个强。但配个无状态系统，照样"失忆"。上次教的，这次忘；上次犯的错，这次重蹈覆辙。问题不在模型，在系统设计——如何让每次工作成为学习时刻，如何把bug变成类别级防线。这就是Compound Engineering真正解决的事。

Skills + Compound Engineering的价值在精炼，不在堆砌。Every.to从通用最佳实践到公司特有的工作流，质量大幅提升。但这个精炼需要考虑：置信度评分、季度重评、低效淘汰。很多团队以为"积累越多越好"，结果Skills变成垃圾堆。好的Compound系统要会"忘记"——把过时的、无效的模式剪掉，比不断添加更重要。

当代码生成速度接近瞬时，瓶颈将从"写代码"转向"验证+学习"。编程场景还能靠更大context window、更快模型缓解，但行业场景的专业知识积累，没法绕过，必须靠复合机制。这也是为什么个人认为行业场景的Skills + Compound组合可能比编程更有价值，因为知识更专有，护城河更深，时间优势更难追赶。

关于护城河，可以从经济角度观察一下。编程的模式会趋同——社区会分享，最佳实践会扩散。但行业场景的投诉数据和处理决策、招聘决策和回顾、催收决策和结果？这些都是业务独有。竞争对手可以抄你的框架，学你的方法论，但很难直接复制6-12个月积累的行业专长(Domain-specific Expertise)。时间的复利，用对了方法，先行者的1年优势，可能等于后来者的2-3年努力。

最难的其实还是思维转变。从"微观管理每个决策"到"信任但验证"，从"今天的贡献者"到"明天的系统训练师"，从"解决当下问题"到"教AI解决未来问题"。技术到位了，但团队如果还在手把手教AI每一步，那就释放不了复合潜力。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述