用寓言讲 AI 工程（一）：老周的铺子，和他的四次改造

老周开了一间木匠铺。

铺子里有个学徒，叫阿快。阿快手快，不累，不顶嘴，也不会故意糊弄人。只是他不知道什么叫好椅子。

你说一句，他做一句。说完了，他就站着，等下一句。

你说得清楚，他就照着清楚的做。你说得含糊，他也照着含糊的做。你忘了交代的，他不会自己补上；你说错了的，他也不会替你纠正。

第一层改造：把话说清楚

起先，老周只会喊一句：

做把椅子。

阿快听了就做。

做出来的椅子，歪瓜裂枣。座面忽高忽低，榫头有粗有细，有的腿还短一截。

老周气得直拍桌子。后来他慢慢琢磨出门道：不是阿快不用心，而是自己说得太粗。

于是他把话改细了：

用榆木。座高四十五。先凿榫，再拼框，最后打磨。做完以后，把缝转过来给我看。

还是那个阿快，这话一换，出来的活就两样了。

一天下来，返工的没几把。

头一回，老周觉得这学徒能用。晚上数着那排齐整的椅子，心里很舒坦。

他还不知道，这只是第一层改造：把话说清楚。

第二层改造：把该看的东西摆到眼前

话说得再细，阿快还是常常卡壳。

他不知道这单客人要几把椅子，不记得上周那把样品是什么样，也不懂铺子的规矩：哪种客人喜欢宽一点的扶手，哪种订单不能用新木料，哪种椅背要留出软垫的位置。

这些背景，老周每回都得从头讲。

讲到后来，嗓子都哑了。

有天晚上，老周忽然想明白了：阿快每天早上脑子都是空的。光靠多喊，不顶用。

于是他不再只改说法，而是改阿快动手前能看见的东西。

• 订单条放在左边。
• 木料样块摆在手边。
• 客人的尺寸单钉在墙上。
• 上周那把样品搁在旁边当参照。
• 铺子常用的款式，画成一张“本铺风格”，挂在正前方。

阿快动手那一刻，眼前正好都是对的料。

椅子又顺了一大截。

从前老周整天钉在阿快身边，寸步不敢离开。现在料摆好了，他终于能撂下活，出门转转。

镇上一直有个大单，他以前不敢接。不是不会做，是怕分不出人手看着阿快。

这回，他接下了。

这是第二层改造：把该看的东西摆到眼前。

第三层改造：给阿快搭一间合适的屋子

可话对了，料也齐了，阿快还是干不出顶好的活。

趁手的锯没有。夹具够不着。车床在屋角，他不敢碰。去后院补料，还常常走错地方。有时候他想拿把小锯，结果差点撞上危险的大锯。

老周这回不再改话，也不再只是摆料。

他开始改整间工作间。

• 常用的工具，摆到伸手就够的地方。
• 允许阿快用的车床，挪到他旁边。
• 危险的大锯前面，加了一道栅栏，让他撞不进去。
• 做好的椅子，只能从一个窗口递出去。
• 不该碰的工具，锁进柜子。
• 后院的料，也按订单分好，只开该开的门。

还是那个阿快。还是那些话。还是那些料。

但换了一间屋，阿快能做的事就不一样了。

椅子又快又稳，出活速度翻了一番。

老周头一次有了“这铺子像个铺子”的感觉。月底一算账，他添了第二张工作台，开始琢磨要不要再招个人。

这是第三层改造：给阿快搭一间合适的屋子。

第四层改造：让铺子自己一轮一轮转起来

不过，屋子搭好了，老周还得守着。

每一把椅子，谁来定目标？谁来取下一单？谁来盯着做完？谁来检查？谁来喊返工？谁来判断今天该停了？

还是老周。

每一轮，都得他亲手摁启动键。

阿快能干，但铺子还不能自己转。

于是，老周做了最后一套装置。

天亮铃一响，装置自己去门口取当天的订单。阿快做完一把椅子，先送到出口架上。出口那里有一把卡尺。晃的、缺腿的、尺寸不对的，直接弹回去重做。墙上挂一块黑板，做成一把记一笔，返工一次也记一笔，免得重复做、漏着做。订单清空了，黑板对上了，装置才停。

这套东西不是一把工具，而是一整圈循环：

取单 → 动手 → 检查 → 返工 → 记录 → 再取下一单 → 直到目标完成。

老周终于不用每一轮都喊开始，也不用每一把都守到最后。

头几天，他睡得很沉。

早上起来，走到铺子里，一屋子椅子。门口的单清空了。黑板上的数对得上。出口卡尺也显示把把合格。

这是他开铺子以来，头一回睡到自然醒。

老周站在屋当中，心里头一回踏实：他不必再当那个从早喊到晚的人了。

这是第四层改造：让铺子自己一轮一轮转起来。

老周的四次改造，在 agent 工程里各有名字

把话说清楚，叫 Prompt Engineering。 它优化的是你对模型说的那句话：目标是什么，约束是什么，步骤是什么，输出长什么样，怎么判断做完。

把料摆到眼前，叫 Context Engineering。 它优化的是模型动手那一刻看得见的全部信息：订单、样品、历史、规则、状态、用户偏好。

给阿快搭一间合适的屋子，叫 Harness Engineering。 Harness 是 agent 的运行外壳：工具、权限、接口、边界、工作流入口、输出通道、安全栅栏，都在这里。

让铺子自己一轮一轮转起来，叫 Loop Engineering。 它优化的是驱动系统奔向目标的循环：取单、执行、验证、返工、记录、停止。

把这四件事并排放：

• Prompt 解决的是：这一句怎么说。
• Context 解决的是：这一刻它看见什么。
• Harness 解决的是：它在什么环境里运行，能碰什么，不能碰什么。
• Loop 解决的是：谁来一轮一轮驱动它，检查它，纠正它，直到任务完成。

这四层不是四选一，也不是后一层替掉前一层。

它们是一层套一层。

你说的话，要被放进它看得见的信息里。它看见的信息，要在你给它搭好的环境里被使用。而这个环境，最终要被一套循环一轮轮驱动起来。

优化的单位一路上移：

从一句话，到一桌料，到一间屋，到一套会自己运转的系统。

对照表：故事里的铺子，对应 agent 工程里的什么

这个故事骗了你哪里

故事讲得太顺，就会骗人。

第一，它容易让人以为这是四级台阶

先 Prompt，再 Context，再 Harness，再 Loop。好像一步一步往上爬，爬完就毕业了。

现实不是这样。

真实的 agent 工程里，四层常常一起调。一个问题看起来像 prompt 不清楚，背后可能是 context 塞错了。看起来像模型不稳定，背后可能是 harness 没有限制工具。看起来像 loop 不收敛，背后可能是 verifier 太粗糙。

这不是严格历史分期，更像一个观察框架。它好用，但不能当铁律。

第二，四层之间的墙是虚的

故事里，“料”和“屋子”分得很清楚。现实里没这么清楚。

比如 agent 能看见哪些工具说明，算 context，还是算 harness？工具调用结果要不要重新塞回上下文，算 context，还是算 loop？权限、记忆、状态、日志、环境变量，到底归哪一层？

不同团队会有不同划法。概念本身不是目的，能帮你定位问题、设计系统，才有价值。

第三，故事没教你怎么判断“是哪层的锅”

故事里每一段毛病都干净对应一层。现实里不是。

一个 agent 输出错了，可能是你说得不清楚，可能是它看见的资料不对，可能是工具权限太大，也可能是 loop 里没人说“不”。更麻烦的是，四层可能一起错。

所以 agent 工程最难的活，往往不是“知道有四层”，而是出问题时能拆开看：到底是话的问题，料的问题，屋子的问题，还是循环的问题。

第四，一个老周搞定四层，是美化

真实世界里，这四件事常常需要不同技能。有人擅长写 prompt，有人擅长做 retrieval 和 context，有人擅长搭工具和权限边界，有人擅长设计 loop、验证器和可观测性。

一个人四层全精，很少。一个团队四层都没人管，倒是常见。

第五，卡尺本身也会骗人

椅子过了卡尺，不代表它真的好坐。尺寸合格，不代表坐上去舒服。流程跑完，不代表结果可靠。模型说完成，不等于任务真的完成。

卡尺很重要。但做完是声明，不是证明。卡尺能决定系统下限，却不能保证系统上限。

这条后面要单独讲。

老周关灯前的那点别扭

四层搭齐以后，老周以为万事大吉了。

可铺子真转起来，每一层都开始冒出新麻烦。料摆多了，阿快反而抓瞎。卡尺测得出晃，测不出好坐。第二个学徒来了，两个人开始抢工具、抢订单、互相改对方的活。订单越来越大，老周开始发现，自己不只是木匠，也不只是师傅，而越来越像一个管系统的人。

但这些都是后面的事。

第一篇先讲到这里：老周终于把铺子改到能自己转起来了。

他确实轻松了。铺子确实更快了。椅子也确实更齐整了。

只是那天早上，他站在满屋椅子中间，忽然有一点说不清的别扭。

这一排椅子，他一把都没碰过。哪把是先做的，哪把返过工，哪把曾经差点过不了卡尺，阿快半夜怎么一遍遍试，黑板上那些数字背后发生了什么，他都不知道。

椅子是好椅子。至少卡尺说是。

可“这些椅子是怎么来的”，老周第一次答不上来。

这点别扭很轻，轻得他当时没当回事。

他只是顺手关了灯。