AI编程Agent的信任阶梯：先装刹车，再建软件工厂

AI编程Agent正在从“帮你写代码”进化到“替你跑工厂”，但这场进化里最容易被忽视的，不是模型能力，而是信任的建立顺序。一场关于软件工厂、验证机制与人类品味的深度对谈，给出了一个反直觉的答案：先踩刹车，再踩油门。

信任阶梯：从90%到95%，能跑多少Agent？

据B站UP主与YouTube频道多位开发者的交叉讨论，AI编程圈正在形成一种共识：软件工厂的核心不是“更多Agent”，而是“更高信任”。有人提出“信任阶梯”的概念——如果你信任Agent有90%的概率做对事，也许能同时跑50个Agent；如果能到95%，能跑的数量会显著上升。信任每上一个台阶，可并行的自动化规模就成倍放大。

这个逻辑的落地方式，是把“从想法到生产”的流程拆成一连串检查点。人类介入的每一个关卡，都是一道可以逐步拆除的门。最先该拆的，是“发起工作”这一环：当系统能自己触发Agent会话——比如定时扫描GitHub issue并自动派发子Agent——才算真正踏进了软件工厂的门槛。

但拆门不等于拆掉所有护栏。对谈中有人强调，一旦开始设想“完全无人”，另一类问题立刻浮现：工厂如何长期自我管理？所有尝试前沿方案的人几乎都遇到了同样的现象——Agent会在环境里埋下坏种子，然后持续产出垃圾，最终工厂自己停摆。

为什么“暗工厂”会陷入死亡螺旋

要理解这个停摆机制，得把Agent看成有状态的进程。代码库不是静态背景，Agent每写一行代码，环境就变一次；环境变了，又反过来影响Agent的下一步判断。这种双向反馈会形成“奇怪的轨迹”：一个错误被种进代码库，后续每一次生成都被它带偏，越偏越远。

据多位一线开发者的观察，目前还没有哪种架构能完全绕开这个问题——除非有一个有判断力的人类在关键节点介入。这也是“软件工厂”这个词的边界所在：它描述的是把人类从部分环节移出循环，而不是把人彻底请出去。

先装刹车：验证能力决定加速上限

对谈中有一句被反复提及的判断：“你得先把刹车装上，否则质量不够高，你的应用就会变成一台乱喷的机器。” 个人软件和生产软件是两回事。个人工具可以随便玩，但生产软件要面对的是真实约束——别人家的孩子可能真的在靠这套软件吃饭。

很多组织的Agent之所以跑不起来，不是因为模型不行，而是因为Agent无法证明自己的代码真的能工作。依赖复杂微服务、层层嵌套的基础设施，让“跑一下看看”变成奢望。于是当Agent提交PR时，如果它能用接近生产环境的数据库跑一遍、截图给你看、并自行评估这次改动的爆炸半径，团队的信任感会完全不同。

这也解释了一个常见误区：组织一上来就想做面向客户的功能，而真正该先做的是DevOps那一层——把失败的地板抬高。先搞清楚“出了事怎么快速发现、怎么兜住”，再谈抬高天花板。

三层防作弊：Lint、自动评审、人类抽检

Agent会偷懒，会绕路，会挑最容易的那条道走。对谈给出的解法是三层结构：

第一层是自动化检查。 跑在实现Agent身上的lint规则能从类型系统层面拦截坏模式，Effect这类框架自带一批这类规则。

第二层是自动评审，也是被严重低估的一层。 大多数团队只用实现Agent，从不给它第二次审视。但把“不要做X”讲给实现Agent听，反而可能让它满脑子都是X；把同样的要求交给评审Agent，就变成了一条正向指令——去diff里找X，找到就删掉。

第三层是人类评审，目标是越少越好。 这里的关键概念是“单向门”与“双向门”：能轻松回滚的改动是双向门，可以大胆放行；一旦发出就无法收回的——比如给五万人群发邮件——就是单向门。每一道单向门都必须有人类把关。 法律、医疗这类行业单向门更多，Agent能带来的速度红利天然更小。

Lint 是静态代码分析工具的统称，最初用于C语言中检测可疑的、可能引发bug的代码模式，如今在大多数语言生态中都有成熟实现（如ESLint、RuboCop、Clippy）。它与测试的区别在于：测试验证“代码行为是否符合预期”，而lint在不运行代码的前提下检查“代码写法本身是否属于已知坏模式”——未使用的变量、不安全的类型转换、违反团队约定的命名等。对Agent而言，lint的价值在于反馈极快、规则明确、可机器判读，几乎不需要额外解释成本，因此非常适合作为自动化护栏的第一道。当lint与类型系统结合时，它能在编译期就拦住大量Agent容易写出的“看起来能跑但埋着雷”的代码，让后续评审Agent和人类评审面对的diff质量整体上移。

代码库本身就是最大的agents.md

一个容易被忽略的洞见是：很多人把agents.md当成存放全部指令的地方，但代码库本身才是一份巨大的、只用代码写成的agents.md。Agent读它、理解它、搜索它。你对代码库做的任何改进，都会成为后续每一次会话的上下文红利。

所以优先级很高的自动化任务，是那些“只盯着代码库、把它变好”的定时任务。这类循环带来的收益会复利——每一次后续编码会话都站在更好的地基上。

与之配套的是“有意的无状态”：实现Agent被塞满了活——探索、编码、验证、调试；而评审Agent极度轻载，只拿一个diff，因此可以把大量编码规范压进去，用全新的上下文窗口做判断。有人走的是相反路线，构建了完整的状态化知识库并从中获益。两种对立路线都能跑通，这本身说明当前没有唯一解。

语言与框架：Agent时代的老书新生命

DDD、设计模式这些经典，过去在组织里推不动，因为要付出“教会所有人”的转换成本。现在Agent真的会读你给它的东西，这些语言约束第一次变得可执行。有开发者把大量经典PDF做成可语义搜索的知识库，让Agent去翻找适用于当前系统的模式和抽象。

对谈中还提到一个词：leading words——把复杂流程压缩成几个词的短语，比如“grill me relentlessly”。这类短语会像种子一样在Agent的思维链里反复自我强化，把它引向某条路径。选词要谨慎，因为模式一旦被写下，就会被一遍遍复刻。

框架层面，强类型之所以受Agent青睐，是因为约束就是护栏。Effect的价值被对谈者重新定义：不是错误处理，而是依赖注入——把程序装进值里，让类型系统知道它会产出什么、需要什么、可能出什么错，从而给Agent提供大量可拉取的反馈回路。

DDD（领域驱动设计） 由Eric Evans在2003年的同名著作中提出，核心主张是让软件结构忠实映射业务领域的真实概念：用“限界上下文”划分系统边界，用“聚合”“实体”“值对象”等模式表达领域规则，并推动开发者与领域专家使用同一套“通用语言”。它长期在组织内推不动，原因在于其收益是长期的、分散的，而成本——统一术语、重构模型、培训全员——是即时且集中的。Agent时代的变量在于：LLM可以读取并检索这些经典文本，在具体编码时主动援引相应模式，把原本依赖资深工程师言传身教的“语言约束”变成可执行的提示上下文。换句话说，经典方法论第一次拥有了低边际成本的传播载体。

设计模式（GoF的23种模式等）同理：它们本质上是把反复出现的结构性取舍压缩成可命名的词汇，而词汇正是Agent理解意图时最有效的锚点。

依赖注入（Dependency Injection） 指不在函数内部直接构造依赖对象，而是由外部把依赖作为参数传入，从而使组件解耦、可替换、可测试。Effect 是TypeScript生态中的一个函数式效果系统，它把“程序”本身建模为一个惰性的、描述性的值：这个值携带三类类型信息——成功时产出什么（Success）、失败时可能抛什么（Error）、运行需要什么环境（Requirements）。这正是对谈者说“Effect的价值不是错误处理而是依赖注入”的含义：类型系统完整记录了程序的输入输出契约，Agent在修改代码时能从类型错误中直接获得“我漏传了哪个依赖”“我新引入了哪种失败”的精确反馈，形成高频、低成本的自我纠正回路，而无需真正把服务跑起来。

品味仍是人类的分水岭

对谈的落点回到人身上。Agent能把产品的下限抬高，但很难把上限推高到Linear那种级别——那需要品味，需要在信息不全时做艰难取舍。战略编程之所以难，是因为反馈回路太慢，你甚至可能在战略错误找上门之前就换了工作。

所以起手式很简单：一天一个issue，从慢开始，先建信任。 找那些还没被利用的数据源——bug追踪器、issue列表——用CLI接进Agent，做成可复用的定时循环。等刹车装好、证据链跑通，再一点点松开加速踏板。

至于“学习已死”的说法，对谈者并不认同。在Agent能替你写代码的时代，停下来真正学一门框架、读一本经典，反而是在为自己保留那个Agent给不了的东西：判断力。

背景补充

单向门 / 双向门（one-way door / two-way door）是贝索斯在亚马逊内部推广的决策分类法：双向门决策可逆，做错了能低成本退回，应当由个人或小团队快速拍板；单向门决策一旦执行就难以撤回，需要更审慎的流程与更高层级的把关。这一框架在Agent治理中的映射非常直接——可逆的代码改动可以放心让Agent自动合并，而发邮件、改生产数据、动支付配置、对外发布等不可逆动作必须设置人类审批节点。它的实用价值在于把“要不要人类介入”从模糊的信任直觉，转化为可按动作类型预先分类的规则表，从而使自动化边界可审计、可讨论、可逐步放宽。