2023年，提示工程（Prompt Engineering）让大模型学会听话；2025年，上下文工程（Context Engineering）解决它该知道什么；紧接着， harness工程（Harness Engineering）教会它如何行动。三层拼图各就各位，但拼完后中间缺了个洞——AI的能力本身，谁来负责？
不是怎么问，不是知道什么，不是怎么执行，而是AI能做什么，以及这套能力如何自我迭代。前OpenAI研究员Andrej Karpathy最近点破这层窗户纸：我们花了三年教AI听说读写，却没人给它写"遗传代码"。
三层旧地基：各管一段，各留一截
提示工程（2022-2024）解决的是接口问题。大模型对措辞极度敏感，同样的意思换种问法，输出质量天差地别。链式思考、少样本示例、系统消息——这套技术栈把"怎么跟AI说话"变成可工程化的问题。工作单元是单个提示词。
上下文工程（2025）解决的是知识问题。提示词不够，模型需要在正确时间拿到正确信息。RAG管道、记忆系统、工具返回结果、对话历史——全部塞进上下文窗口里管理。Karpathy的原话是：「我不会说提示工程有多重要，更重要的是上下文工程。」
Harness工程（2025-2026）解决的是编排问题。上下文告诉AI知道什么，harness告诉AI怎么动。多步骤代理工作流、工具调用管理、错误恢复、生产环境可靠性——这套脚手架把大模型从"推理引擎"变成"行动实体"。工作单元是整个代理harness。
三层架构层层叠加，互不取代。但叠加完之后，一个基础问题悬在空中：这些能力从哪来？
手工造轮子的困境：能力冻结在出生那一刻
现在的答案是：人类手工造。开发者写工具函数，团队打包Skill，工程师硬编码API封装。能力是手工艺品，诞生时什么样就什么样，后续靠人工更新维护。
小规模能跑通。但遇到三种情况直接崩盘：
第一，能力组合爆炸。10个基础工具两两组合就100种，三三组合1000种——手工覆盖？不现实。
第二，环境持续漂移。API版本迭代、业务规则调整、用户行为变化，昨天好用的能力今天可能埋雷。
第三，反馈闭环断裂。能力表现好不好，靠人定期Review，等发现时用户已经流失。
根子在于结构：我们把AI能力当成静态文物来保管，而非活的生命体来培育。提示工程给了AI耳朵，上下文工程给了AI记忆，harness工程给了AI手脚——但没人给它DNA，让能力可以诞生、测试、筛选、迁移、进化。
进化工程：设计"能力生态"而非"能力清单"
进化工程（Evolution Engineering）的核心转向：不手工造每个能力，而是设计选择环境——适应度标准、竞争场域、传播渠道、安全免疫系统——让能力在里面自我演化。
类比生物学或许更清晰。传统工程思维是"上帝造人"：设计师画好每个零件图纸，工人按图生产。进化工程思维是"设计生态系统"：设定光照、水分、捕食关系，让物种自己冒出来、自己卷、自己迭代。
具体怎么落地？原文没给完整蓝图，但方向明确：
适应度函数自动化。不是人拍脑袋定"这个能力好不好用"，而是埋点采集真实用户反馈——任务完成率、用户满意度、资源消耗——让数据说话。
能力基因库。把能力拆解为可重组的模块（类似生物的基因），支持交叉、突变、横向转移。一个场景验证过的错误处理逻辑，自动迁移到相似场景。
安全免疫系统。进化不是放任，需要边界。能力上线前过沙箱测试，运行时监控异常行为，发现毒性及时隔离——这套机制本身也是进化出来的。
为什么是现在？三层地基终于打完了
进化工程不是凭空冒出来的概念。提示工程、上下文工程、harness工程三层成熟，才让这个第四层成为可能——没有可靠的执行层，进化出来的能力没地方落地。
这也解释了为什么大厂和小团队都在往"代理平台"方向挤。表面看是拼谁的Agent更智能，底层拼的是谁的能力进化效率更高。手工造100个Skill的团队，打不过自动进化出1000个能力变体的系统。
Karpathy的表态值得玩味。作为前OpenAI核心成员，他现在更关注"上下文"而非"提示词"；而这篇提出"进化工程"的文章，作者同样来自OpenAI系背景。一个信号是：顶尖研究者正在从"怎么让模型更聪明"转向"怎么让系统更自洽"。
文章结尾抛了个问题没回答：当AI能力开始自我进化，人类工程师的角色会变成园丁、育种师，还是动物园管理员？
热门跟贴