35分钟写完代码，为什么还要等3个半小时才有人看？

一个Agent能提交代码，不等于它能稳定接手一项真实工作。Warp CEO Zach Lloyd描述过一条完整链路：团队成员在公开Slack频道提交需求，系统先对输入分流，建立Linear工单，再完成实现和GitHub PR，之后工厂Agent还会做计算机使用验证，留下展示最终界面行为的视频或其他证据。

这条链路里有个数字很扎眼：一次任务从启动到PR可能只需三十五分钟，但PR到第一次人工评审仍可能需要三个半小时。这个数字描述的是该团队的实际情况，不该外推成普遍基准。它的意义在于提醒：只优化代码生成速度，拥堵会转移到审查、QA和跨团队协调。

工厂不是单一Agent

Warp对软件工厂的解释，校正了一个常见想象——它不是一个把需求丢进去、自动吐出代码的单一Agent。按Zach Lloyd的描述，一座工厂由仓库、配置、MCP服务和不同角色的Agent组成，而且这些组成部分都被定义为代码。它关心的不只是某一次生成成功，而是整个系统在持续运行中怎样被观测、评估和改进。

把步骤排在一起看，价值不只是更快地生成代码，而是让需求如何提出、改动如何发生、验证看到了什么，都存在同一条可追溯的运行链路中。Warp把计算机使用QA放进流程，正是为了让代码之外的行为也能有证据，而不是把审查者留在一堆难以复现的聊天记录前。

软件工厂的第二层是管理与学习。团队会观察运行速度、成本、每个PR需要多少人工交互，并使用LLM as a judge等方式给跨运行结果打分。代码审查目前仍由人承担，这一点没有被包装成已经解决的问题。对团队来说，更重要的不是立刻消除人工，而是知道人工在哪些地方纠正了系统，以及这些纠正是否能转成下一轮的规则、样本或测试。

Zach Lloyd还描述了回放历史任务的做法。因为模型、配置、工具和流程定义都能冻结成一个版本，团队可以用相同的旧任务重跑不同配置，比较成本与质量的变化。他提到，在积累大约二十到二十五个失败样本后，观察者Agent可以根据失败模式提出修改工厂定义的建议。这不是一个放之四海皆准的样本门槛，但它把失败从一次性事故变成可以归档、比较并用于改进的工程对象。

先定义判断，再记录运行

Jev的讨论有一个容易被忽略的起点：它并不把自己首先描述为聊天助手，而是面向软件控制流的System One模型。这里的System One指可校准的小决策，即快速、局部、可嵌入的判断。软件不一定需要模型写一篇完整解释，它可能只要模型判断一条记录该归到哪里、一个字段是否缺失，或者下一步该调用哪个工具。

TypeSafe AI CEO在访谈中把训练路线称为RLCD，也就是强化学习校准决策。它追求的不是一句听起来最令人满意的回答，而是让模型给出的概率和它实际掌握的信息相称。这样，系统可以把高置信度、可复核的输出直接交给下一步，把不确定的输出送去查询、规则校验或人工处理。对生产软件而言，知道何时不该继续自动推进，和答对本身一样重要。

需要保留的是，这里关于RLCD的说法来自受访者及其公司，相关方法尚未公开发表，不能当作已经被独立验证的通用能力。但它提出的问题很有价值：当模型开始参与业务流程时，团队究竟需要一个能聊天的伙伴，还是一个能被系统评估和调度的判断单元？

访谈给出的工程答案是把复杂任务拆成小而可测的语义决策，并以结构化状态代替巨型提示词。巨型提示词往往把规则、历史、工具结果和例外同时塞进一次请求，可以在演示中工作，失败时却难以定位。若把任务拆开，分类、抽取、工具选择和最终提交都能有各自的输入、输出和验收方式；某一步变差时，也可以只重测这一环，而不必把整条链路当成黑箱。

可靠性在这里也有更实际的含义。访谈把它描述为相近输入应得到相近结果，而不是要求每次都生成一模一样的文字。真实数据会变化，真正重要的是系统能辨认哪些变化影响判断，哪些变化不应改变结果。一条工单的措辞略有不同，是否仍应被分到同一队列；一项资料缺少关键字段，是否应直接中断而不是继续猜测——这些都是可以单独设计样本和验收标准的问题。

对希望把模型接进产品或内部工具的团队，这篇访谈给出的启发很具体：先挑一个边界清楚、能够判对错或由人复核的决策，记录它的输入、状态、输出与人工纠正。这样积累的不是一次成功提示，而是一份可以在模型更新时复用的评测资产。Jev的重点不在于取代确定性系统，而是让模型承担适合它的判断，把权限检查、精确计算和状态提交交回原有系统。

模型会更替，工作地图不会

UiPath CEO Daniel Dines的判断可以概括成一句话：模型会更替，企业长期需要保留的是工作地图。所谓工作地图，并不只是画出部门和步骤的流程图，而是记录一项工作如何实际完成：会经过哪些系统、遵循哪些程序、遇到哪些例外，以及谁有权在什么条件下改变路径。企业场景之所以难，往往不在标准动作，而在经验人员知道何时不能按标准动作办。

访谈举了财务和客户场景的例子。表面上，一张发票或订单似乎有固定规则；实际上，某个客户可能有特殊约定，某次地址变化可能意味着需要另走流程。这类判断未必写在表单字段里，却影响最终结果。如果模型只看得到通用知识和当前输入，它很难自然获得这些业务语境。企业真正需要沉淀的不是一段越来越长的提示词，而是能让人和系统共同理解的流程、例外与权限信息。

为此，UiPath提到cartographer agent，也就是通过访谈领域专家、记录实际桌面操作、追问例外原因来生成过程地图的方式。它的关键不在于监控本身，而在于把原本隐含在做事过程里的理由显式化。一个好的追问不是只问做了什么，还会问为什么这次改了路径、什么条件会触发人工介入、哪些系统数据可以作为依据。来自不同人员的记录被汇总后，流程才可能接近实际运行方式。

Daniel Dines还区分了概率性能力与确定性执行。AI可以帮助设计自动化、理解自然语言、生成实现方案；但需要精确执行的环节，应交给能稳定复现的程序、规则和系统。模型可以提议，系统需要负责权限、状态、测试和最终提交。这样并不是限制AI的价值，而是让它在适合的位置发挥作用，同时留下审计和验证的空间。

工作地图还有一个现实好处：它给企业保留模型更替时的选择权。若知识只存在于某家模型的提示与对话中，换模型或换工具时就难迁移；若流程、例外、系统入口和审批方式被沉淀，新能力可以在清楚的边界里接入。流程图当然不等于无人值守自动化，原访谈也提到连接器、权限、安全、测试与人工干预仍是生产化工作。把这些约束写清楚，反而让自动化的可用范围更可判断。

这篇访谈还把视角带回组织。员工与客户建立的信任、跨部门判断的语气，未必都能被岗位指标直接量化，却可能决定流程的实际质量。记录工作地图不只是为替代操作做准备，也是为了识别哪些经验应被保留、何时应该让人继续参与。对企业而言，一个适合开始的动作是挑选高频流程，请真正处理例外的人写下为什么不能照常办理。

控制平面与循环工程

InfoQ以真实的OpenClaw缺陷报告为线索，提出生产级Agent需要一个控制框架。模型可以提出操作建议，但状态归属、有序变更、有界工作以及限定范围的审批，不应由模型临场决定。控制平面的角色，是把这些约束变成可执行的提交规则和可查验的凭证。

文章强调不变量的价值。一项任务的状态究竟由谁写入，什么条件下可以重试，哪些操作必须获得审批，若没有明确归属，多个Agent与人工参与者就可能对同一对象做出冲突变更。问题不只是模型会不会答错，而是系统能否阻止一个看似合理的提议越过权限边界。把它和Jev一起读会更清楚：前者关注模型输出是否可校准，后者关注输出进入系统后是否受控。

大淘宝技术则系统梳理了Loop engineering，把工程循环拆成六个必备动作与六类支撑组件。它讨论的重点不只是让agent执行任务，而是让任务有观察、评估、反馈和下一次调整的闭环，避免一次生成后就失去对结果的判断。文章还把自动化判定、失败模式和权限分层放入同一张图里。一个动作是否应该自动化，不只取决于模型是否做得到，还取决于失败是否容易发现、影响范围是否可控、是否存在足够清楚的回滚和人工接管方式。

对已经在使用编码Agent的读者，它可以作为流程体检表。检查自己的循环是否只包含生成和执行，还是也记录了验证信号、失败原因与改进入口。Loop engineering的实质，是把一次工具调用变成可持续改善的工程过程，而不是把更多步骤交给自动化后就停止观察。

把性能目标变成可重复运行的测试

Max Woolf的实验把性能优化任务交给智能体式LLM，但没有只要求它写得更快。他先设定明确的通过与失败性能约束，也加入防作弊护栏，再让系统反复迭代Rust实现。报道的案例覆盖机器学习与日常软件，速度提升介于两倍到二十倍。

这个范围来自特定任务、基线与评测环境，不能离开原始测试直接当作通用预期。实验最有价值的部分，是把benchmark、正确性要求和禁止走捷径的规则提前写进任务。没有这些条件，模型可能通过删功能、牺牲边界情况或只优化一次运行来制造表面上的提升。

对工程团队而言，这是一种很清楚的任务设计：先让性能目标变成可重复运行的测试，再让Agent参与优化。这样，人类不需要预先知道所有微优化技巧，也能保留对结果的验证权。它也说明了Warp所强调的回放和评分为何重要，好的优化不是一次漂亮结果，而是可以再次测到的改进。

非凡产研对深演智能创始人的采访，提出企业级AI像一位聪明却涉世未深的新毕业博士。文中所说十个人加一套AI软件做出一百个人的增长，是对潜在产能的判断，不是可以直接复制的业绩承诺；它真正值得展开的部分，是企业场景为何仍需要深度业务理解。受访者把FDE的工作解释为把客户问题转化为产品，而不是单纯驻场定制。客户往往只说得出痛点，团队还要识别问题是否真实、能否抽象、如何标准化并验证效果。文中认为，模型天然难以获得企业的数据、知识与工作流，这些才构成长期的护城河。

晚点则回顾了达摩院医疗AI十年的路线：从单病模型起步，经由多病联筛，逐步走向通用医疗影像模型。最新的DAMO RADAR论文登上Science，报道指出它面向腹部增强CT，可覆盖十八个器官的一百四十六种病症，并尝试零样本诊断。医疗影像的难点在于错误代价很高，模型不能只追求看起来合理的答案。文章描述团队先从胰腺癌等具体筛查问题出发，累积专病能力和真实场景，再尝试将一张CT用于更多疾病风险的识别。医疗结论必须服从临床验证与专业判断，文中的技术进展不能替代个体诊断。

把这些线索放在一起，实践顺序是清楚的：先定义判断，再记录运行，最后把组织的隐性知识放进可治理的边界里。对没有完整平台的团队，最值得借用的也不是某一套工具名，而是最小闭环——选一类重复任务，明确谁可以发起、什么算完成、哪些人工纠正需要记录、失败该怎样分类。只要这些信息能回放，模型、提示词和工具的改变才有可比较的参照。