# BestBlogs 早报：Jev 决策模型与 Warp 软件工厂 - 来源：ginobefun (@hongming731) - 发布时间：2026-09-22 08:24 - AIHOT 分数：40 - AIHOT 链接：https://aihot.news/items/cmuby5qr404jsro9irkni3knk - 原文链接：https://x.com/hongming731/status/2102192210318164301 ## AI 摘要 TypeSafe AI CEO 在 Latent.Space 访谈中介绍 Jev——面向软件控制流的 System One 模型，采用 RLCD（强化学习校准决策）训练，追求概率与实际信息相称，相关方法尚未公开发表。 ## 正文 https://x.com/i/article/2102191541515382784 BestBlogs 早报 · 09-22｜TypeSafe AI CEO 谈 Jev 决策模型，Warp CEO 分享 AI 软件工厂实战手册 在线阅读本期早报 BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。 导语 一个 Agent 能提交代码，不等于它已经能稳定接手一项真实工作。真正进入团队协作后，问题会变得具体：这一步判断能不能复核，失败能不能回放，遇到例外时谁来决定下一步？今天的内容从模型、工程和企业语境三个角度回答这些问题。 Jev 把复杂工作拆回可校准的小决策；Warp 把 Slack 发起的任务一路记录到 PR 和界面验证；UiPath 则把长期资产放在工作地图上，追问流程、例外和经验如何被保存。它们并非同一套产品路径，却构成了一个清楚的实践顺序：先定义判断，再记录运行，最后把组织的隐性知识放进可治理的边界里。 如果你刚读过 9 月 19 日关于 Agent 业务评测治理，今天可以把它当作更接近操作层的补充。评测不只是给模型打一个总分，也可以嵌入每一次决策、每一次交付和每一条业务流程，让下一次改动有可追溯的依据。 ★ 精讲一：Jev：面向生产软件的快速决策模型 来源：Latent.Space · BestBlogs 评分：90 Jev 的讨论有一个容易被忽略的起点：它并不把自己首先描述为聊天助手，而是面向软件控制流的 System One 模型。这里的 System One 指 可校准的小决策，即快速、局部、可嵌入的判断。软件不一定需要模型写一篇完整解释，它可能只要模型判断一条记录该归到哪里、一个字段是否缺失，或者下一步该调用哪个工具。把模型放进这类位置，衡量标准也随之改变。 TypeSafe AI CEO 在访谈中把训练路线称为 RLCD，也就是强化学习校准决策。它追求的不是一句听起来最令人满意的回答，而是让模型给出的概率和它实际掌握的信息相称。这样，系统可以把高置信度、可复核的输出直接交给下一步，把不确定的输出送去查询、规则校验或人工处理。对生产软件而言，知道何时不该继续自动推进，和答对本身一样重要。 这一路线与传统围绕人类偏好或可验证答案的训练目标形成对照。受访者的判断是，单纯把模型训练成善于对话，未必能让它成为稳定的软件依赖；程序化任务需要更清楚的状态、接口和误差边界。需要保留的是，这里关于 RLCD 的说法来自受访者及其公司，相关方法尚未公开发表，不能当作已经被独立验证的通用能力。但它提出的问题很有价值：当模型开始参与业务流程时，团队究竟需要一个能聊天的伙伴，还是一个能被系统评估和调度的判断单元？ 访谈给出的工程答案是把复杂任务拆成小而可测的语义决策，并以结构化状态代替巨型提示词。巨型提示词往往把规则、历史、工具结果和例外同时塞进一次请求。它可以在演示中工作，失败时却难以定位。若把任务拆开，分类、抽取、工具选择和最终提交都能有各自的输入、输出和验收方式；某一步变差时，也可以只重测这一环，而不必把整条链路当成黑箱。 可靠性在这里也有更实际的含义。访谈把它描述为相近输入应得到相近结果，而不是要求每次都生成一模一样的文字。真实数据会变化，真正重要的是系统能辨认哪些变化影响判断，哪些变化不应改变结果。例如，一条工单的措辞略有不同，是否仍应被分到同一队列；一项资料缺少关键字段，是否应直接中断而不是继续猜测。这些都是可以单独设计样本和验收标准的问题。 对希望把模型接进产品或内部工具的团队，这篇访谈给出的启发很具体：先挑一个边界清楚、能够判对错或由人复核的决策，记录它的输入、状态、输出与人工纠正。这样积累的不是一次成功提示，而是一份可以在模型更新时复用的评测资产。Jev 的重点不在于取代确定性系统，而是让模型承担适合它的判断，把权限检查、精确计算和状态提交交回原有系统。接下来的 Warp，正展示了这些判断进入交付流程后，团队如何把每一次运行变成可比较的记录。 ★ 精讲二：工程团队的 AI 软件工厂实战手册 | Warp CEO Zach Lloyd 来源：How I AI · BestBlogs 评分：90 Warp CEO 对软件工厂的解释，很适合用来校正一个常见想象：它不是一个把需求丢进去、自动吐出代码的单一 Agent。按照他的描述，一座工厂由仓库、配置、MCP 服务和不同角色的 Agent 组成，而且这些组成部分都被定义为代码。它关心的不只是某一次生成成功，而是整个系统在持续运行中怎样被观测、评估和改进。 演示中的入口是公开 Slack 频道。团队成员提交需求后，系统先对输入分流，建立 Linear 工单，再完成实现和 GitHub PR。之后，工厂 Agent 还会做计算机使用验证，留下展示最终界面行为的视频或其他证据。把这些步骤排在一起看，价值不只是更快地生成代码，而是让需求如何提出、改动如何发生、验证看到了什么，都存在同一条可追溯的运行链路中。 这条链路也暴露了自动化真正会遇到的瓶颈。访谈里提到，一次任务从启动到 PR 可能只需三十五分钟，但 PR 到第一次人工评审仍可能需要三个半小时。这个数字描述的是该团队的实际情况，不应外推成普遍基准；它的意义是提醒我们，若只优化代码生成速度，拥堵可能转移到审查、QA 和跨团队协调。Warp 把计算机使用 QA 放进流程，正是为了让代码之外的行为也能有证据，而不是把审查者留在一堆难以复现的聊天记录前。 软件工厂的第二层是管理与学习。团队会观察运行速度、成本、每个 PR 需要多少人工交互，并使用 LLM as a judge 等方式给跨运行结果打分。代码审查目前仍由人承担，这一点没有被包装成已经解决的问题。对团队来说，更重要的不是立刻消除人工，而是知道人工在哪些地方纠正了系统，以及这些纠正是否能转成下一轮的规则、样本或测试。 受访者还描述了回放历史任务的做法。因为模型、配置、工具和流程定义都能冻结成一个版本，团队可以用相同的旧任务重跑不同配置，比较成本与质量的变化。他提到，在积累大约二十到二十五个失败样本后，观察者 Agent 可以根据失败模式提出修改工厂定义的建议。这不是一个放之四海皆准的样本门槛，但它把失败从一次性事故变成可以归档、比较并用于改进的工程对象。 对没有完整平台的团队，最值得借用的也不是某一套工具名，而是最小闭环：选一类重复任务，明确谁可以发起、什么算完成、哪些人工纠正需要记录、失败该怎样分类。只要这些信息能回放，模型、提示词和工具的改变才有可比较的参照。Jev 让模型输出有更清楚的决策边界，Warp 则让工程运行有更清楚的证据边界。要让这类系统进入企业现场，还需要知道业务为什么会在某个例外处偏离标准流程。 ★ 精讲三：Daniel Dines：工作流程而非模型才是 AI 时代最有价值的资产 来源：20VC with Harry Stebbings · BestBlogs 评分：90 UiPath CEO 的判断可以概括成一句话：模型会更替，企业长期需要保留的是工作地图。所谓工作地图，并不只是画出部门和步骤的流程图，而是记录一项工作如何实际完成：会经过哪些系统、遵循哪些程序、遇到哪些例外，以及谁有权在什么条件下改变路径。企业场景之所以难，往往不在标准动作，而在经验人员知道何时不能按标准动作办。 访谈举了财务和客户场景的例子。表面上，一张发票或订单似乎有固定规则；实际上，某个客户可能有特殊约定，某次地址变化可能意味着需要另走流程。这类判断未必写在表单字段里，却影响最终结果。如果模型只看得到通用知识和当前输入，它很难自然获得这些业务语境。因而，企业真正需要沉淀的不是一段越来越长的提示词，而是能让人和系统共同理解的流程、例外与权限信息。 为此，UiPath 提到 cartographer agent，也就是通过访谈领域专家、记录实际桌面操作、追问例外原因来生成过程地图的方式。它的关键不在于监控本身，而在于把原本隐含在做事过程里的理由显式化。一个好的追问不是只问做了什么，还会问为什么这次改了路径、什么条件会触发人工介入、哪些系统数据可以作为依据。来自不同人员的记录被汇总后，流程才可能接近实际运行方式。 受访者还区分了概率性能力与确定性执行。AI 可以帮助设计自动化、理解自然语言、生成实现方案；但需要精确执行的环节，应交给能稳定复现的程序、规则和系统。这个区分与今天前两条的逻辑一致：模型可以提议，系统需要负责权限、状态、测试和最终提交。这样并不是限制 AI 的价值，而是让它在适合的位置发挥作用，同时留下审计和验证的空间。 工作地图还有一个现实好处：它给企业保留模型更替时的选择权。若知识只存在于某家模型的提示与对话中，换模型或换工具时就难迁移；若流程、例外、系统入口和审批方式被沉淀，新能力可以在清楚的边界里接入。流程图当然不等于无人值守自动化，原访谈也提到连接器、权限、安全、测试与人工干预仍是生产化工作。把这些约束写清楚，反而让自动化的可用范围更可判断。 这篇访谈还把视角带回组织。员工与客户建立的信任、跨部门判断的语气，未必都能被岗位指标直接量化，却可能决定流程的实际质量。记录工作地图不只是为替代操作做准备，也是为了识别哪些经验应被保留、何时应该让人继续参与。对企业而言，一个适合开始的动作是挑选高频流程，请真正处理例外的人写下为什么不能照常办理。它为 Jev 的小决策和 Warp 的运行回放补上了最重要的业务语境。 速览 智能体控制框架：生产级 AI 智能体的控制平面、不变量与审批边界 来源：InfoQ · BestBlogs 评分：90 InfoQ 以真实的 OpenClaw 缺陷报告为线索，提出生产级 Agent 需要一个控制框架。模型可以提出操作建议，但状态归属、有序变更、有界工作以及限定范围的审批，不应由模型临场决定。控制平面的角色，是把这些约束变成可执行的提交规则和可查验的凭证。 文章强调不变量的价值。例如，一项任务的状态究竟由谁写入，什么条件下可以重试，哪些操作必须获得审批，若没有明确归属，多个 Agent 与人工参与者就可能对同一对象做出冲突变更。问题不只是模型会不会答错，而是系统能否阻止一个看似合理的提议越过权限边界。 把它和 Jev 一起读会更清楚：前者关注模型输出是否可校准，后者关注输出进入系统后是否受控。团队可以从一份操作清单开始，列出哪些动作允许自动提交，哪些动作只能生成草案，哪些状态改变必须留下审批记录。这份边界会比抽象地要求 Agent 更可靠更有用。 Loop engineering：把 agent 放进工程循环 来源：大淘宝技术 · BestBlogs 评分：91 大淘宝技术系统梳理了 Loop engineering，把工程循环拆成六个必备动作与六类支撑组件。它讨论的重点不只是让 agent 执行任务，而是让任务有观察、评估、反馈和下一次调整的闭环，避免一次生成后就失去对结果的判断。 文章还把自动化判定、失败模式和权限分层放入同一张图里。一个动作是否应该自动化，不只取决于模型是否做得到，还取决于失败是否容易发现、影响范围是否可控、是否存在足够清楚的回滚和人工接管方式。这个视角能帮助团队跳出只比较模型能力的讨论。 对已经在使用编码 Agent 的读者，它可以作为流程体检表。检查自己的循环是否只包含生成和执行，还是也记录了验证信号、失败原因与改进入口。Loop engineering 的实质，是把一次工具调用变成可持续改善的工程过程，而不是把更多步骤交给自动化后就停止观察。 10 个人加一套 AI 软件，做出 100 个人的增长：AI 时代企业服务的算账逻辑 来源：非凡产研 · BestBlogs 评分：91 非凡产研对深演智能创始人的采访，提出企业级 AI 像一位聪明却涉世未深的新毕业博士。文中所说十个人加一套 AI 软件做出一百个人的增长，是对潜在产能的判断，不是可以直接复制的业绩承诺；它真正值得展开的部分，是企业场景为何仍需要深度业务理解。 受访者把 FDE 的工作解释为把客户问题转化为产品，而不是单纯驻场定制。客户往往只说得出痛点，团队还要识别问题是否真实、能否抽象、如何标准化并验证效果。文中认为，模型天然难以获得企业的数据、知识与工作流，这些才构成长期的护城河。 这条内容与工作地图形成业务侧呼应。对服务商来说，现场需求不能只变成一次性项目清单，能否沉淀成下一个客户也能使用的能力，决定交付是否会成为产品。对采购方来说，也可以反问自己：哪些增长环节有足够清楚的数据、目标和验收条件，值得先交给人机协作去验证？ 阿里达摩院医疗 AI，十年拼出一张图 来源：晚点LatePost · BestBlogs 评分：91 __XPOSTER_7j53u_IMAGE_7__ 晚点回顾达摩院医疗 AI 十年的路线：从单病模型起步，经由多病联筛，逐步走向通用医疗影像模型。最新的 DAMO RADAR 论文登上 Science，报道指出它面向腹部增强 CT，可覆盖十八个器官的一百四十六种病症，并尝试零样本诊断。 医疗影像的难点在于错误代价很高，模型不能只追求看起来合理的答案。文章描述团队先从胰腺癌等具体筛查问题出发，累积专病能力和真实场景，再尝试将一张 CT 用于更多疾病风险的识别。这种从具体难题到更广泛任务的路径，比直接宣称通用能力更值得研究。 医疗结论必须服从临床验证与专业判断，文中的技术进展不能替代个体诊断。它对其他行业的启发，在于高要求场景的扩展往往依赖长期的数据、验证和流程积累。想把 AI 做进关键决策，先把一个真正重要且可验证的问题做深，仍然是比追逐泛化叙事更扎实的办法。 通过要求智能体加速代码，写出比最先进库更快的 Rust 代码 来源：Max Woolf's Blog · BestBlogs 评分：90 Max Woolf 的实验把性能优化任务交给智能体式 LLM，但没有只要求它写得更快。他先设定明确的通过与失败性能约束，也加入防作弊护栏，再让系统反复迭代 Rust 实现。报道的案例覆盖机器学习与日常软件，速度提升介于两倍到二十倍。 这个范围来自特定任务、基线与评测环境，不能离开原始测试直接当作通用预期。实验最有价值的部分，是把 benchmark、正确性要求和禁止走捷径的规则提前写进任务。没有这些条件，模型可能通过删功能、牺牲边界情况或只优化一次运行来制造表面上的提升。 对工程团队而言，这是一种很清楚的任务设计：先让性能目标变成可重复运行的测试，再让 Agent 参与优化。这样，人类不需要预先知道所有微优化技巧，也能保留对结果的验证权。它也说明了 Warp 所强调的回放和评分为何重要，好的优化不是一次漂亮结果，而是可以再次测到的改进。 不换机器，也不造机器人：这家公司让几十年前的老工厂直接接进 AI 来源：人人都是产品经理 · BestBlogs 评分：90 人人都是产品经理介绍美国创业公司 Harmoni 的做法：在旧工厂机床旁放置平板电脑，把人、机器、订单与 ERP 数据连接起来，让既有设备进入工业 AI 的信息链路。它没有从全面替换设备开始，而是优先解决现场数据与操作界面彼此断开的现实问题。 制造现场常常拥有寿命很长的机器，也拥有大量依赖经验的操作。若系统只能看到订单或 ERP 的一端，就很难理解另一端发生了什么。平板成为信息入口后，操作人员、机床状态和生产安排可以更接近同一份工作记录，后续分析与辅助决策才有落点。 这条案例把今天的抽象讨论拉回一个朴素条件：AI 是否有用，取决于一线数据、现有软件与人的操作能否连起来，而不是是否先购买全新硬件。对准备做工业智能化的团队，先找出最影响协作却尚未被记录的现场信息，往往比先谈更大的模型更能推动项目。 为下一阶段 AI 制定标准 来源：OpenAI News · BestBlogs 评分：87 OpenAI News 呼吁由美国牵头推进前沿 AI 的国际技术标准，议题包括递归自我改进，以及评估、人类监督和事件报告。它把标准视作各方在能力快速变化时建立共同技术语言的一种方式，而不只是一份原则声明。 标准不会替一家团队完成本地的权限设计、测试或验收，但会影响这些做法能否被比较和沟通。评估怎样描述，监督如何记录，出现事件后哪些信息需要报告，都会决定不同组织之间能否理解彼此的风险控制方式。文章讨论的是全球层面的倡议，真正的落实仍要看后续参与方和具体规范。 从今天的内容回看，这个话题并不遥远。当团队开始保留评测结果、批准记录和失败事件时，已经在为更可交流的治理方式打基础。无论是一个小决策、一条 PR，还是一项企业流程，能否说明它如何运行、由谁批准、出了问题怎样追溯，都是进入更广泛协作的前提。 今日小结 回顾今天的内容，Jev 讨论如何让模型判断可校准，Warp 展示如何把交付运行变成可回放的记录，UiPath 则提醒企业把流程、例外和经验沉淀成工作地图。控制框架、工程循环、性能评测与工业现场案例分别补上了这些能力进入不同场景时所需的边界与证据。 时间有限时，建议先读 Jev，明确哪些任务可以拆成可验收的小决策；再看 Warp，理解记录、评分与回放如何组成改进闭环；若你负责业务或组织转型，则把 UiPath 的工作地图与非凡产研的企业服务访谈连读，检查现有流程是否已经写清了例外与权限。 你所在的团队是否已经有一类任务，能够同时留下输入、验收结果和人工纠正？又有哪些经验仍只存在于少数人的日常判断里？欢迎在评论区分享你看到的有效做法或最难记录的例外，一起讨论这个问题：哪些内容应先进入工作地图？ 👉 近期早报 • BestBlogs 早报 · 2026-09-21 • BestBlogs 早报 · 2026-09-20 • BestBlogs 早报 · 2026-09-19 • BestBlogs.dev 第 113 期：模型之外的尺子 • BestBlogs.dev 第 112 期：可托付的智能 • BestBlogs.dev 第 111 期：经验复利 BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」，欢迎体验和关注我们。