在过去（或者说现在），软件行业实际上是一套工场手工业流水线，想想我们生产软件的形式：
-
PM/BA从相关方收集产品需求，整理好后传递给开发
-
-
-
一直以来，业界不断在对这个流水线进行优化，“敏捷开发”、“TDD”、“DevOps”、“持续交付”，都是在尝试优化这个流水线，加快交付速度，提高流水线的吞吐：
但是，这些所有的实践都无法避免一个问题：代码是人用键盘敲出来的，把代码写出来是这个流水线里关键的阻塞点。
后续所有的自动化流程都需要等待编码完成才可以运转，而需求也会因为等待“程序员可用”而堆积在Backlog里。
所以，软件工场想要提高产出，想要扩大产线规模，就要招聘更多的程序员去写代码，就要让程序员们加班996花一天中的更多时间去写代码。
但是，无论如何，人是要吃饭睡觉休息的。当然如果可以的话，工场主绝对是希望自己的工人们是可以7×24小时产出的
总之，软件行业原本实际上是手工业，编码是这个流水线里最无法自动化，最不通畅的节点，但是又是最直接生产价值的节点
而AI Agent编程的出现改变了这个形式，使得软件的生产可以探索另一种可能。
在流水线上，人和Agent没有什么区别，我们人类在开发的时候，其实也是在做和Agent同样的事：
-
-
-
单纯“写代码”这项任务，是完全可以交给Agent来完成的。
实际上我们日常使用Coding Agent也是这么做的（我不止一次听到过有人说，哪怕只需要调整一行代码，也宁愿打字让Agent去做而不是自己打开IDE去做）
问题在于Agent没有被集成到生产线里，相反，Agent只是处在生产线里的人手里的工具，本质上和IDE、编译器甚至键盘没有什么区别。
应该很多人在使用Coding Agent的时候都有意识到一个现象：我发出一个指令，等待Agent完成，我检查成果，然后给出下个指令。
这个工作流是很没有效率的，因为这个流程是人在驱动Agent工作，人不动，Agent就不动。
许多Agent(Harness)和LLM都尝试在解决这个效率问题，比如现在最新的LLM的后训练都会侧重于“解决长任务”，Codex等也推出了’/goal’指令，或者现在说的很多的Agent Loop。这些都是在尝试减少Agent工作对来自人的指令的依赖。
但是这些都还在做一件事：让Agent成为更好用的工具。
这就是前面所说的工坊手工业，Agent是工具，工具服务于人，人利用工具。
但是如果反过来想想呢：能不能让Agent自主工作，而人来服务Agent呢？
我想应该有人有着和我一样的经历，感觉开一个Agent做事等Agent完成太浪费时间了，所以尝试开多个Agent，去并行地做多件事，哪个Agent出结果了就过去看，连轴转结果把自己忙晕掉。
这个时候其实就已经有点“人服务Agent”的意思了。
但是还不够，还要更进一步，让Agent替代人进入流水线，让Agent直接响应来自流水线上游的工件（比如需求文档作为输入上下文），自动化地开始编码工作。
这个时候，不再是人使用Agent完成任务，而是Agent自主地去完成任务，而人需要去服务Agent，在Agent遇到问题的时候去介入解决。
这样，就从根本上转变了软件生产的方式，在流水线上，机器是主体，人是机器上配套的附属物，原本的人利用工具，转变为人服侍机器。
这样做的最大好处是，流水线上编码这个环节可以动起来了，它不用休息，不生病，不请假，它可以在深夜凌晨写代码，它也可以同时有多个会话去写多个任务的代码。
如果需要扩大生产规模，只需要多开几个Agent，多开几条流水线即可。
设想一个问题：如果你要在你的软件上增加一个新功能，它什么时候开始能够进入这个流水线？
对于传统的，成熟实践了持续交付的开发的生产线来说，是开发写完代码，将代码合并到主干分支后，这个流水线才开始启动。（如果是未能良好实践CI/CD的软件工坊就更糟了，产线上的每个环节的每个人，都要等待下一个人可用，然后把手中的工件移交过去）
而对于引入Agent开发流水线的生产来说，一个成熟的需求（上下文），就是流水线的起点，当我们把一个需求标记为就绪，投入到需求池里的那一刻，流水线就已经开始启动了，不需要人工去驱动，后面都是可以24*7自动化运转的流水线节点，我们只需要等待对产品进行验收就好了。
-
-
方案出来后交给开发团队进行为期一个星期的996封闭冲刺
-
赶出MVP后，PM上手体验了下发现不行要调整，又开了两天的会，又是一个星期的996冲刺……
-
等到终于可以投放市场后，收集市场反馈，再开会，再冲刺。
（注意，这里你几乎无法通过扩大团队的方式来缩短工期，你只能通过要求成员加班延长工作时间来赶进度）
-
团队聚集在会议室里，和Agents一起讨论产品方案，一个Agent根据会议室里的语音生成会议笔记，另一个Agent自动根据会议笔记当场制作产品原型分享给参会人检查
-
方案确定后，和Agents一起进行需求拆分和规划，每一个被确认的需求当场进入流水线排队等待其它Agents认领
-
Agent认领需求后自动进行方案设计、代码实现、自动化审查等，代码集成后自动发布到预生产环境。
-
第二天早上，团队们到达会议室的时候，昨天讨论出的产品已经就位等待参会人验收了
在以前做微服务架构的时候，有这么一个说法：你必须长到这么高，才能用微服务（You must be this tall to use microservices）
这句话的意思是，采用微服务是有门槛的，你需要具备一些前提条件才能使用微服务，比如需要有快速配置计算资源的能力，需要能够进行快速的自动化的部署，需要有能力监控故障和快速回滚等，在缺少这些的时候，强行使用微服务，只会引入更多的复杂性，最后适得其反。
在AI开发流水线上也是如此，你原本的软件生产流水线需要足够成熟，然后再引入AI才能具备最大价值。
比如最根本的一点，前面说过，对于流水线上的编码后的部分，业界已经有非常成熟的实践了，有持续集成，有容器化自动部署，有基础设施即代码，有测试左移，如果你当前的流水线已经具备了这些（我们用持续交付一词概括），编码之后的所有流程里的所有环节都畅通无阻，只有编码是最严重最关键的阻塞点，那么引入AI进入流水线会非常显著并且迅速地释放出流水线的生产力。
相反，如果现有的流水线就不够成熟，从测试到部署，从分支策略到发布策略，每个环节都有着大大小小的卡点，每个环节都是缓慢且僵硬的话，那么单纯把编码Agent加入流水线所能提供的帮助并不会很大，它只能节省开发者的精力和时间（也许还未必），但是从整个生产线来看，生产力并没有提升。
首先要明确一点：质量是速度的前提，速度是质量的副产物。
软件质量说简单些就是生产出正确的软件，这个影响是在整个流水线上都生效的，质量缺陷会导致工件在流水线上回退，从而延长了走完整个交付流水线的周期。
在软件工程实践里，这个问题就是“如何尽量让人写出正确的代码”，通常的实践是开发和PM/BA进行沟通理清需求，建立测试覆盖、结对编程、Peer Review等。
对于Agent来说，这个问题主要其实就是“如何尽量让Agent写出正确的代码”，手段实际上是类似的：保障递送给Agent的需求上下文清晰明确，多Agent协作进行代码审查，在流水线中加入进行冒烟测试的Agent等，当然，就像你可以雇佣更有经验的开发者一样，你也可以购买编码能力更强的LLM来降低出Bug的概率，但是，Bug总是无法完全避免的，因此，想要生产高质量的软件，这些工程实践也是必不可少的。
而对于Agent编程来说，另一个问题尤为重要，即“软件内部质量对Agent效率的影响”。
Agent编程时，问题本身，和当前已存在的软件代码，会共同作为上下文输入给模型，Agent在解决我们提出的问题时，它不可避免地，也要去面对当前软件本身的问题。
这点对于人来说也是一样的，我们人力进行古法编程时，也是有着同样的问题，当前解决方案往往会成为我们需要解决的问题的一部分，比如当代码复杂性过高我们会很难理解代码进行工作，比如有可能做的时候发现当前的工作方式设计有问题必须要进行调整。
但是人类开发者在面对问题的时候有着LLM所不具备的优势：人会执着于写出正确的代码，而LLM经常会尝试绕过问题，或者对问题视而不见（等等，真的只有LLM会这样吗……）
总之，软件内部质量对Agent的影响比对人类开发者的影响更大，如果软件的复杂性过高导致问题难以短时间解决，自然会有Leader指着Deadline过来PUA你让你去解决，通常你想想办法，加加班，也是能够解决的。
但是LLM不一样，首先，和人类开发者不同，让LLM加班是有成本的，其次，LLM听不到领导的催促，也不吃PUA，所有的PUA话术都会成为无价值的上下文从而进一步阻碍其完成任务。并且，如果LLM解决不了一个问题，那就是真的解决不了，你让它运行一天一夜也解决不了。
所以在使用Agent开发时，维护软件的内部质量是一件很重要的事情，使用Agent进行流水线开发更是如此，你必须精心地去控制住软件的内部复杂性，你要小心翼翼地进行架构设计，你要约束住模块的接口和模块之间的交互，你要让测试健康、有效且迅捷，你要清理Agent生成的代码里那些丑陋难闻的地方。
甚至，有时候，你需要把整个流水线关停，来做维护和清理工作，否则你的软件会连带着你的流水线一起腐烂。
上图来自Martin Fowler的文章《Is High Quality Software Worth the Cost?》
如果你是正在将已存在的混乱的软件生产线改造为自动化Agent开发流水线，那问题会更加严重，你当前项目里的所有混乱之处——每一处架构偏移，每一处丑陋设计，甚至每一个不一致、有歧义的命名——都会成为流水线上的藤蔓阻碍着流水线的运转。
想一想，你有多大的信心能够放手让Agent来完成开发工作？问问你的团队，当他们在使用结对模式让Agent来做开发工作的时候，是否要盯住Agent的输出流来时刻准备纠正？是否不断地烧着token不断出现问题需要返工？是否要不断纠正AI的“最佳实践”来适配企业内部的当前实践？
对于一个复杂的，充满混乱的蹒跚着前进的软件项目来说，引入AI进行开发并不会实质上提高团队的生产力，因为这种项目无法建立起可靠的自动化流水线，这种项目一直都是靠着一个个底层螺丝钉们勉强地推着走的，其解决方案本身的复杂性甚至可能超出了其解决的问题的复杂性。
在这种项目上引入AI编码，实际上就像是为一线流水线工人换了把更有力气的榔头而已，也许能给团队里的开发者省些力气，但是这个依然是基于人力推动的流水线交付的速度并没有什么显著提升，你也无法对流水线规模进行有效扩张。
甚至，AI的参与会将已经充满混乱的项目积累混乱的速度进一步升级，导致不仅没有提高生产力，反而阻碍了生产力的提高。
所以，不愿意触碰对整个生产线的改造，只想通过采购Token就能提高开发团队的生产力，不过是脱离软件生产前线的领导们在尝试用Agent做一些非生产性工作比如帮自己读一读下属们的工作汇报后做的一场春梦而已。
但是，初创团队没有这些问题，而有雄心的团队会去解决这些问题，当这一切发生的时候，就是新事物取代旧事物的时候了。
夜雨聆风
