第八课　从编码Agent到软件工厂：验证循环决定自主上限

软件开发本来就是一座工厂，只是多数公司没有画出来

Reyes把软件组织描述成一个循环。外部信号先进入：客户反馈、错误报告、内部对话和业务要求；团队排序、规划并形成任务；代码与文档成为事实来源；更改经过审查、测试、安全扫描、静态分析、lint与类型检查；最后发布、监控，再产生新信号。

“信号”比“需求”更宽。客户在电话里抱怨一项功能，生产监控出现异常，Slack里有人发现重复手工操作，管理层决定进入新市场，这些都可能成为软件工作的起点。人类团队会给信号赋予不同权重，把一部分变成计划，再由工程师写进代码。软件上线后产生的新错误、使用数据和反馈，又返回循环开头。

这条循环在每家公司都存在，却经常只存在于人的协作习惯里。某位产品经理知道哪条客户反馈应该进入季度计划，某位资深工程师知道安全审查要找谁，某个团队用自动测试，另一个团队依靠人工质量保证（QA）。单个环节都有工具，环节之间却没有统一状态。所谓软件工厂，首先是把这套隐式生产过程画出来，再判断AI能在哪些连接处持续接手。

很多公司拥有这些部件，却没有把它们设计成系统。信息散在工单、Slack、代码库和个人经验里，验证标准也因团队而异。编码Agent进入这种环境后，能生成代码，却不知道完整生产链怎样闭合。

Factory的FDE站在“产品最前端”：进入大型客户，把这条循环显式化，将现场信号送回Droid和平台。它不是传统专业服务，因为目标不只是完成客户项目，而是改变Agent框架与软件工厂本身。

Reyes专门划清了与咨询项目的边界。如果客户拿着大型咨询公司的报价，请Factory用Droid代为完成一场代码现代化，项目本身可能带来可观收入；但如果Factory工程师只是替客户执行迁移，公司得到的更像项目收入，产品未必因此变强。Factory不希望FDE成为使用自家工具的专业服务团队。

“矛尖”意味着另一种工作：FDE进入最复杂、最关键的客户，听工程负责人怎样规划，也观察一线工程师怎样使用Agent；把安全、成本、可观测性、模型路由和运行框架里的问题持续传回产品。客户项目仍要产生结果，但结果应该通过产品系统实现，并推动这套系统更容易在下一家企业“自组装”。

自组装并不意味着真正零配置，而是规模约束。大型客户可能有4.5万名乃至更多工程师、数万代码库，任何依赖Factory人员逐个安装、调试和维护的方案都无法覆盖。FDE要帮助建立一套部署模型，让客户团队可以按统一治理逐步扩张，而不是把现场人员变成永久操作员。

模型不是系统

企业很少愿意把命运押在单一模型上。模型价格、能力与政策变化很快，不同任务适合不同模型；敏感环境还要求私有网络、本地或隔离部署。Factory强调模型无关的框架（model-independent harness）：模型可以替换，任务上下文、权限、工具、轨迹数据、验证与治理仍由企业掌握。

所谓harness，可以把它想象成模型周围的工作环境。它决定Agent能看见哪些代码，能调用哪些工具，任务运行多久，失败后从哪里恢复；也记录模型采取过的动作、花费和验证结果。相同模型放进不同harness，实际能完成的工作可能完全不同。企业采购的若只是一个模型入口，便很难形成自己的运行资产。

模型无关还有现实的性能理由。代码生成、长上下文分析、视觉检查和快速分类未必由同一模型最擅长；价格与延迟也不同。平台可以按任务路由模型，但必须把路由决定和结果纳入同一套审计。否则“多模型”只会变成多个互不相通的风险边界。

Reyes甚至用“潜艇里也能运行”形容隔离能力。这个说法强调的是边界：Agent系统不能假设永远连着公共互联网或把代码发送到外部服务。对大型企业，采用速度往往由安全、数据所有权和集中治理决定，而不只是基准分数。

在金融、医疗和政府环境中，代码、运行日志乃至提示上下文本身都可能是敏感数据。客户不仅要知道模型输出了什么，还要控制数据流向哪里、哪些团队可以调用哪些模型、轨迹保留多久。Factory强调企业应拥有软件工厂中流动的trace（Agent执行轨迹）和数据，因为这些记录会成为后续评测、改进和合规的基础。若记录全部被封在供应商系统里，企业很难真正演化自己的工厂。

“软件工厂靠建设、不是买来即用”（built, not bought），并不是说企业不能采购平台，而是说软件工厂无法靠一次安装凭空出现。平台提供Agent、编排、治理和观察的构件，客户仍要投入工程工作，把自己的信号、代码、验证和发布路径连接起来。FDE的责任是帮助客户建立这套能力，而不是假装一个许可证已经完成组织改造。

Agent准备度，不是一句“模型更聪明了”

Reyes提出一个有用判断：一个代码库能让Agent自主工作多长，取决于它拥有多少高质量、确定性的验证循环。

类型检查能明确告诉Agent某类错误；单元测试和集成测试能验证行为；安全扫描能发现已知风险；编译与部署检查能确认更改能否进入环境。验证越及时、越可机器读取，Agent越能自己发现偏差并修正。

确定性在这里很重要。测试通过或失败、类型匹配或不匹配、安全规则命中或没有命中，都能转化成明确反馈。Agent可以据此修改代码再运行，形成密集循环。若反馈只是“资深工程师觉得不太对”，它既难自动读取，也往往到代码审查末端才出现，Agent此前的长链工作便可能全部建立在错误方向上。

反过来，如果完成标准只能由一名资深员工“看起来差不多”判断，Agent即使会写很多代码，也很难长时间自主工作。

Reyes把这一点与模型后训练联系起来。复杂任务中的模型需要密集奖励信号来保持方向；生产环境里的编译、测试和检查正是类似信号。验证器数量不是越多越好，关键是覆盖真实失败并快速返回。一个永远通过的测试不会增加准备度，一个运行六小时且结果模糊的检查也很难支撑长任务。

Reyes把这种条件称为Agent Readiness（Agent准备度）。提升Agent准备度常会暴露企业原有的工程问题：构建无法在干净环境重现，测试互相影响，代码所有权不清，安全检查只在上线前人工进行。即使最后不使用Agent，修复这些问题也会改善人类工程师的交付。因此，FDE带来的第一批价值有时不是更多AI代码，而是让软件系统第一次拥有可重复的完成定义。

软件工厂：每一次验证都给Agent一条可学习的反馈

长任务需要有界、可验证的任务容器

Factory把长时间运行、多步骤、多Agent协作的任务称为Missions。关键不是让Agent“自由工作几天”，而是把任务放进边界清晰的容器，持续保留上下文、检查点和验证。

Missions把规划阶段和执行阶段分开。人先给出一个有界任务，说明目标以及“完成”由哪些检查证明；随后系统持续投入推理和工具调用，直到通过验证或触发升级。人的角色不是每隔几分钟继续提示，而是在开始前设计任务，在出现无法形式化的判断时介入。

Reyes的强主张是：如果“完成”能够被验证，许多任务今天就能交给AI解决。现实中仍有大量完成标准难以形式化，例如视觉质量、界面闪烁或复杂用户体验；这正是FDE要与客户一起建设新验证器的地方。

演讲提到大型代码迁移、合规与生物医药等场景，以及客户环境中约15%至20%的当前自主程度和更高的潜在上限。这些是Factory的项目经验和估计，不代表普遍能力。值得保留的是衡量方法：不要问“Agent会不会写代码”，要问“某条工作流中有多少步骤能在治理边界内自主完成”。

Reyes提到数千万行代码迁移、金融研究和生物医药问题，意在说明只要任务能被验证，长时Agent可以进入非常复杂的领域。这类陈述必须连同条件一起读：不是模型下载后就能处理数千万行代码，而是组织先要建立环境、拆分任务、提供工具和验证器。任务规模并不会取消工程约束，只会放大它。

Factory还区分了“有多少工作完全自主完成”与“每次人工干预之间Agent能连续执行多少动作”。演讲中的15%至20%和“80%以上”分别接近这两类口径，不能混成一个自主率。某个系统可能只有少数任务真正端到端无人参与，但在这些任务里，Agent已经能连续执行很长。准确区分指标，才能知道下一步应该扩大任务覆盖，还是减少现有任务的中断。

开放式视觉问题仍然是边界。终端界面是否闪烁、交互是否让人困惑，有时很难被现有自动检查稳定捕捉。Factory自己的核心harness也不能因此宣称完全自主；相反，团队需要设计新的视觉验证或保留人工判断。这再次说明，自主上限不是一条固定的模型能力曲线，而是验证工程不断向外推进的边界。

低垂果实之后，难的是重设计流程

最容易的一批任务也许占30%到40%：文档、简单测试、模式明确的迁移和维护。剩余部分通常要求团队改变工作流、补齐验证、整理代码库和权限。企业采用Agent的后半程不是继续换更强模型，而是重构软件生产系统。

Reyes说，大约三四成“低垂果实”可以直接让Droid修复，例如补齐明确的静态检查问题。剩余部分之所以难，不一定是代码更复杂，而是会触碰人的工作方式。更严格的自动检查可能让开发者觉得过度挑剔，新的合并门槛会改变团队节奏，补测试又需要先明确历史行为。FDE必须设计过渡，不能用Agent效率为名突然把整套开发流程强加给人。

这一步要求同时理解技术和组织。验证策略要足够强，才能给Agent反馈；又不能让人类工程师每天被低价值警告淹没。权限要允许Agent执行工作，又不能绕过责任边界。优秀设计通常从少数高价值流程开始，用实际缺陷下降、周期缩短或发布稳定性证明改变值得，再逐步提高标准。

这也是FDE存在的理由。它必须同时理解客户的代码库、治理、安全与业务目标，找出第一批能证明价值的任务，再把成功模式扩到成千上万代码库。

Epcot：从未来城市构想变成主题公园的警示

Reyes用Epcot做比喻。迪士尼最初把它想象成未来城市的实验样板，后来成为主题公园。企业AI试点也常如此：为了展示而搭建的“未来工作方式”非常漂亮，却依赖特殊团队、手工数据和例外权限，无法复制到普通代码库。

Epcot原本是“未来实验原型社区”的构想：先建一座可运行的未来城市，让其他城市借鉴交通和规划。最终落地的却是一座供人参观的主题公园。它可以启发想象，却不等于普通城市能够照着迁移。企业AI样板同样容易因环境过于精心设计，被业务团队视为一次展览。

好的样板必须既展示未来，又允许组织真正走到那里。它要使用可以扩张的身份、权限、验证和治理；要记录成本与失败；要证明普通团队而不只是明星工程师能够重复。

样板太保守也不行。如果它与旧流程几乎没有区别，只节省几分钟，组织看不到改变的必要。FDE需要走一条窄路：展示足够先进的未来，让人相信软件工厂值得建设；同时保留现有组织能理解的接口、控制点和迁移步骤，让团队相信自己走得到。

成功样板的真正产出不是演示视频，而是一套扩张模型：哪些代码库最适合下一批，最低验证要求是什么，谁负责治理，采用成本和结果怎样衡量。客户团队拿到这套模型后，应能自己把能力复制到更多部门。FDE若永远是唯一会操作样板的人，项目就仍然停留在主题公园阶段。

Factory寻找的FDE也由此带有混合特征：技术沟通能力、业务判断、管理层表达、系统思维，以及像创始人一样从模糊问题走到完整结果的倾向。

Reyes特别看好三类人。前创始人习惯在没有清晰边界的情况下同时处理产品、技术和商业；开发者体验或高质量开发环境背景的人，已经在思考怎样让其他工程师更有效；系统型人才则喜欢建模组织中的流动、关闭反馈循环。产品经理如果愿意快速补足技术深度，也可能适合，因为软件工厂的每个环节——代码审查、事故响应、QA、测试——都可能成长为独立产品面。

人的长期位置也随之改变。工程师不再只直接修改软件，而会越来越多地设计、维护和改进“构建软件的系统”：选择信号，设定验证，观察失败，调整工具和治理。这不是工程工作的消失，而是抽象层级上移。FDE处在这个变化最前面，因为他必须先在客户真实组织里证明新层级如何工作。