软件工厂真正的竞争力，可能不再是“能调度多少 Agent”，而是能不能在任务执行过程中持续判断：下一步到底该做什么。

最近一段时间，AI 软件工程正在发生一个很明显的变化。

以前，我们讨论的是：

怎么让一个 Agent 写代码？

后来变成：

怎么让多个 Agent 协同写代码？

再后来，大家开始搭建所谓的 Software Factory——软件工厂：

一个系统负责拆任务，一个系统负责调度 Agent，不同 Agent 负责编码、测试、安全检查、部署，整个过程还可以持续记录状态、插入人工审批。

从架构上看，这已经越来越完整。

但一个新的问题也开始出现：

当 Agent 真正开始工作之后，谁来判断它现在做得对不对？

不是判断它“有没有在运行”，而是判断：

它是不是还在朝正确目标前进？

它写出来的东西是不是逐渐偏离需求？

测试结果到底是真的有效，还是只是“绿了”？

当前任务是不是突然需要安全专家？

下一步是不是应该换一个 Worker？

上下文够不够？

事情是不是已经跨过了自动化边界，需要人接手？

这些问题，本质上都不是传统意义上的“任务调度”。

它们更像是一个新的东西：

控制平面（Control Plane）。

1

一、软件工厂已经解决了“怎么干活”，但还没完全解决“怎么判断”

今天的软件工厂架构其实已经越来越成熟。

大型软件目标可以被拆成 Feature、Milestone 和具体任务，再交给不同的 Agent Worker 执行。

执行过程中，还可以加入独立的 Validator，对代码、测试和结果进行验证。

整个系统甚至可以做到：

Agent + Orchestrator + Validator + Cloud Runtime + Observability + Eval + Human-in-the-loop

换句话说：

“把事情交给 Agent 去做”已经不再是最大的难题。

真正困难的是：

Agent 正在做的时候，系统能不能实时判断它到底做得怎么样。

例如，一个 Worker 正在运行。

传统监控可能告诉你：

• Worker-7 还活着
• 调用了 26 次工具
• 修改了 14 个文件
• 测试命令返回 0
• Pull Request 已经创建

这些信息都没有错。

但它们仍然回答不了最关键的问题：

这个 Agent 到底有没有越来越接近目标？

一个正在运行的 Agent，并不等于一个正在取得进展的 Agent。

于是，软件工厂开始需要一种新的能力：

高频、低成本、持续运行的语义判断。

2

二、JEV 做的事情：不是写代码，而是判断“现在发生了什么”

这也是 JEV 有意思的地方。

TypeSafe AI 将 Jev 定义为其第一款 System One 模型。

它的工作方式与传统大模型稍有不同：

输入的是当前系统状态和结构化问题；

输出的是结构化的、带概率性质的判断。

原文提到的三种问题类型分别是：

Noul：某个陈述为真的概率是多少？

Choice：从固定选项中选择一个结果。

Score：按照一定的等级，对当前状态进行评分。

例如，可以把当前软件工厂状态交给 Jev，然后连续询问：

Worker 是否已经卡住？

测试是否足够？

当前实现是否满足需求？

是否应该切换 Worker？

当前任务是否应该交给人工？

这些问题不需要一个昂贵的大模型每次重新进行长链路推理。

它更像一个实时运行在 Agent 执行环路旁边的：

“语义状态估计器”。

这正是现在很多软件工厂里缺失的一层。

/三、一个更完整的软件工厂架构，应该长什么样？/

原文提出了一个很清晰的三层架构。

2.1

第一层：Generative Workers

也就是我们熟悉的 Agent Worker。

它们负责真正“干活”：

读代码、调用工具、修改文件、运行测试、分析日志、处理错误、不断尝试解决问题。

这一层是生成式的、开放式的。

它拥有很强的自主性。

2.2

第二层：Semantic Supervisor

这一层就是 JEV 这类模型最适合出现的位置。

它不负责真正执行任务。

它负责观察任务状态，并回答一些非常具体的问题：

• worker_stuck
• tests_sufficient
• requirements_satisfied
• needs_human

也就是：

Agent 现在处于什么状态？

2.3

第三层：Deterministic Policy

真正决定“能不能这么做”的，仍然应该是确定性的代码。

例如：

• 最大重试次数
• Token 预算
• 权限范围
• 审批条件
• 状态转换
• 是否允许停止 Worker
• 是否允许部署

这些都不应该交给概率模型直接决定。

原文有一句话非常关键：

Semantic inference should estimate. Deterministic code should govern.

可以翻译成：

语义模型负责估计，确定性代码负责治理。

这其实是整个架构最重要的边界。

不要让一个模型既负责判断：

“这个 Agent 是不是卡住了。”

又负责决定：

“生产环境允许它重试多少次。”

前者是模糊判断，后者是系统政策。

两者必须分开。

3

四、当“语义控制”进入执行环路，会发生什么？

一旦有了这一层，软件工厂的能力会发生一些变化。

3.1

1. 不只是路由模型，而是路由 Worker

今天大家经常讨论：

模型路由。

这个请求到底应该交给哪个 LLM？

但对于软件工厂来说，真正需要路由的东西其实是：

Worker。

比如：

这个任务继续交给当前编码 Agent？

还是切换到安全 Agent？

最新代码变化是不是意味着需要数据库专家？

验证应该使用浏览器、自动化测试还是人工检查？

而且，这种路由不能只在任务开始时做一次。

因为：

任务本身会在执行过程中不断发生变化。

一个最开始看起来像前端 Bug 的问题，在排查之后可能最终发现是认证系统的问题。

传统静态编排往往还会坚持最开始的任务分配。

而语义控制平面，可以根据实时状态重新判断：

谁才是现在最合适的 Worker。

3.2

2. 监控“进展”，而不是监控“活动”

这是另一个非常重要的区别。

现在的 Agent 可观测性已经非常丰富。

你可以记录：

Tool Call、Token、Shell Command、Patch、Test Result……

理论上，什么都能记录。

但问题是：

记录得越多，不代表越理解 Agent 到底发生了什么。

你知道 Agent 做了 100 次操作，

却不知道它是不是在原地打转。

语义监督层的作用，就是把大量底层事件压缩成少量真正有控制价值的状态：

进展、卡住、偏离、完成置信度、是否需要验证……

当这些信号出现之后，软件工厂才真正拥有了一个可以用于控制的反馈信号。

3.3

3. 在“读取上下文”的时候进行路由

上下文越多，真的越好吗？

软件企业里的上下文其实非常庞大：

需求文档、架构设计、历史事故、负责人信息、政策、PR 历史、Runbook、依赖关系图、历史 Agent Trace……

问题来了：

难道每个 Worker 都把全部上下文读一遍？

显然不现实。

成本高，而且大量无关信息进入上下文之后，反而可能降低效果。

传统向量检索解决的主要是“相似度”。

但软件工程中的“相关性”往往是动态变化的。

例如：

“哪些信息和实现这个 API 有关？”

与

“哪些信息和安全审查有关？”

以及：

“哪些信息和判断这次部署风险有关？”

其实是完全不同的检索任务。

所以，一个快速的语义分类器，可以在读取上下文的那一刻判断：

现在到底应该把哪一部分知识送进昂贵的大模型。

这意味着：

未来的软件工厂可能不是简单地“拥有更多上下文”，

而是能够：

每一次读取上下文时，都动态决定什么才真正重要。

3.4

4. 增加护栏，却不把 Agent 变成死板的工作流

这里存在一个一直很难解决的矛盾。

一端是：

严格状态机。

优点是可控，但 Agent 几乎没有发挥空间。

另一端是：

完全自主 Agent。

Agent 可以自由探索，但很多决策都发生在 Agent 内部，系统越来越难控制。

语义控制平面提供了一种中间方案：

让 Agent 保持探索能力，但把关键控制点留在 Agent 外部。

例如，每经过一个 Checkpoint，就重新判断：

• 继续
• 调整方向
• 验证
• 停止
• 升级给人工

这样既不会把 Worker 的整个轨迹提前写死，

也不会完全放任 Agent 自己决定一切。

3.5

5. 持续执行“语义层面的政策检查”

当然，有些安全边界必须是硬性的。

例如：

权限、Sandbox、网络访问、Secret、生产环境部署权……

这些绝不能依赖概率模型。

因为这些属于：

硬安全边界。

但组织里的很多政策并没有那么简单。

例如：

一个代码修改，从权限角度看完全合法，但修改范围已经大到必须经过安全审查。

或者：

Worker 本来有 Repository 写权限，但开始修改原本不属于任务范围的文件。

再或者：

一次看起来很普通的依赖升级，却意外影响到了受监管的数据链路。

这些问题需要的是：

语义层面的判断。

这里依然要强调：

JEV 不应该直接“执行政策”。

它应该提供语义信号，

然后由确定性的控制代码决定最终动作。

这样才能把整个系统组合起来。

3.6

6. 让人工介入变成动态路由，而不是固定审批节点

现在很多 Human-in-the-loop 系统，还是按照预先定义好的节点运行。

例如：

到这里必须人工审批。

到那里必须人工确认。

但真实世界里的软件开发并没有那么规整。

Agent 很可能在一个设计工作流时完全没预想到的位置突然遇到不确定性。

这时候，如果系统只能按照固定流程走，就会很僵硬。

更合理的方式是：

让控制平面持续判断：

当前任务是不是已经超出了 Agent 的自主运行范围？

如果是，

那么“人”就不再是一个特殊的审批节点，

而变成一种普通的路由目标。

也就是说：

需要人，并不是因为流程写到了这里，而是因为当前状态告诉系统：现在应该让人接管。

/五、Foreman：一个很小，但很有意思的实验/

为了验证这个思路，原文作者还介绍了一个开源项目：

Foreman。

它本质上是一个非常轻量的实验系统：

一边运行 Codex Worker，

另一边启动一个并行的 Supervisor Loop。

Worker 持续进行软件开发工作。

Supervisor 则不断收集一些有限的仓库和运行时信息，再向 Jev 提出一组语义问题。

之后，把返回的概率交给 Python 编写的策略逻辑。

于是形成这样一个闭环：

Worker 干活 → 收集状态 → Jev 判断 → Policy 决策 → 继续 / 调整 / 停止 / 验证 / 人工

这里还有一个很重要的设计原则：

3.7

“Typed”并不等于“正确”

假设 Jev 给出了：

worker_stuck = 0.91

这表示模型高度认为 Worker 已经卡住。

但这个判断仍然可能是错的。

因此，这套架构真正有价值的地方，并不是：

让模型永远做对判断。

而是：

让不确定性显式存在，让政策逻辑保持透明。

模型负责给出判断。

系统决定怎么处理判断。

/六、为什么 Policy 必须写在代码里？/

Foreman 的真正控制逻辑，放在 Policy 层。

它会优先处理安全问题和生命周期限制，然后才考虑生产效率。

逻辑大致可以理解为：

1if needs_human:
2    return ESCALATE
3
4if worker_is_active and (off_track or stuck or policy_drift):
5    return STEER_WORKER or STOP_WORKER
6
7if finish_ready and verification_resolved:
8    return FINISH
9
10if should_verify:
11    return START_VERIFIER
12

这个设计有一个很大的优点：

JEV 可以被替换，但控制逻辑不会跟着一起消失。

今天用 Jev。

明天换成另外一种分类器。

甚至后天完全不用模型。

只要输出仍然符合控制层需要的语义信号，下面的 Policy 仍然可以继续运行。

这意味着：

模型是可替换组件，控制策略才是系统资产。

/七、还有一个经常被忽略的问题：不要“每个 Token 都问一次模型”/

如果 Agent 每输出一行日志，就调用一次语义分类器，显然会产生大量浪费和噪声。

Foreman 的实现采用了事件驱动模式：

通过 asyncio.Queue 汇总 Worker 产生的事件，将短时间内的大量事件合并处理，同时设置最小评估间隔。

但一些特别重要的生命周期事件，可以绕过普通的延迟策略，立即触发评估。

这个设计其实比“JEV 到底有多强”更加值得关注。

因为在生产系统里，

评估频率本身就应该成为一个控制参数。

例如：

任务稳定运行时，可以低频检查。

但如果出现：

• 连续失败
• 权限变化
• 大规模 Diff
• 大量 Tool Call
• 进入部署阶段

就应该提高检查频率。

进一步发展下去，

甚至可以让：

评估调度器自己也变成自适应的。

/八、离真正用于生产，还有哪些距离？/

原文对这一点其实非常谨慎。

JEV 这种语义评分机制，目前仍然存在一些现实问题：

语义评分还没有针对这个使用场景完成充分校准；

误报和漏报都可能带来成本；

Foreman V1 一次只运行一个 Coding Worker；

本地执行环境也不能简单等同于真正的隔离边界；

当前的数据持久化更偏向调试和检查，而不是生产级可靠存储。

所以，距离真正进入生产环境，还需要补上几个关键环节。

4

第一，建立自己的校准数据集

不要凭感觉设定阈值。

应该持续记录：

观察状态 → 语义评分 → 系统动作 → 人工覆盖 → 最终结果

然后利用真实历史数据不断调整阈值。

5

第二，把“Worker 评估”和“Supervisor 评估”分开

这两个问题其实是不同的 Benchmark。

第一个问题：

Agent 有没有把 Bug 修好？

第二个问题：

Supervisor 有没有在正确的时间介入？

不能因为 Agent 最终把问题解决了，就认为 Supervisor 的决策一定正确。

反过来也一样。

6

第三，引入时间维度和滞回机制

不能因为某一次评分突然变差，就立刻杀掉 Worker。

更合理的做法是加入：

趋势、宽限时间、多次连续评估、历史干预记录……

避免系统在：

继续 → 停止 → 继续 → 停止

之间来回震荡。

7

第四，严格限制控制权限

这是最重要的一条。

语义系统可以：

提出状态转换建议。

但它不能绕过：

Sandbox、IAM、Branch Protection、Deployment Approval 等确定性安全机制。

也就是说：

AI 可以提出“停下来”的建议，但真正赋予它执行权限的仍然必须是系统本身。

/九、真正有价值的，不一定是模型，而可能是“决策历史”/

这是整篇文章里我认为最值得软件工程团队思考的一点。

未来，前沿模型还会继续变化。

Agent Harness 会继续变化。

Orchestrator 也会逐渐收敛到类似的基础能力。

那么，什么东西最终会真正形成组织自己的技术壁垒？

原文给出的答案是：

Control Policy + Decision History。

也就是：

大量真实运行过程中积累下来的“小决策”。

例如：

什么时候应该重试？

什么时候应该换 Worker？

哪些上下文真正有用？

什么时候值得启动验证？

哪些信号预示任务正在失败？

什么时候人工介入真正改善了结果？

这些数据不会一次性产生。

它们会随着软件工厂长期运行不断积累。

而且这种积累具有明显的复利效应。

两家公司可能使用：

同一个 Coding Model。

甚至使用：

相同的 Agent Framework。

但最终的软件工厂依然可能表现出完全不同的效率。

差异来自哪里？

很可能来自：

更好的状态判断、更合理的策略阈值、更精准的上下文选择，以及更完整的反馈闭环。

/十、下一代软件工厂，可能更像“工业控制系统”/

这也是原文最后最核心的判断。

未来的软件工厂，未必会简单地变成：

更多 Agent + 更多 Agent + 更多 Agent。

真正的发展方向，可能更接近：

工业控制系统。

Agent 就像一个能力越来越强的执行单元。

它们负责真正完成复杂工作。

而控制平面负责持续观察系统状态，并不断回答：

现在应该继续吗？

应该换人吗？

应该验证吗？

应该调整方向吗？

应该停止吗？

是不是需要人接管？

于是，一个完整的 AI 软件工厂会形成一个新的闭环：

Agent 负责创造

Semantic Layer 负责理解状态

Policy 负责做出确定性控制

Human 负责处理超出自治边界的问题

这比单纯堆叠更多 Agent，更像一套真正可以长期运行的生产系统。

/写在最后/

从这个角度看，JEV 真正有意思的地方，并不是：

“又出了一个新的 AI 模型。”

而是它对应了一个正在逐渐浮现的架构趋势：

AI 软件工程的竞争重点，正在从“生成能力”向“控制能力”移动。

过去，我们关心 Agent 能不能写出代码。

现在，我们开始关心：

Agent 写代码的时候，系统能不能实时理解它正在发生什么。

更进一步：

系统能不能根据这些判断，在正确的时间，让它继续、调整、验证、停止，或者把控制权交给人。

当 Agent 越来越多、越来越自主之后，

真正稀缺的可能不再是“会干活的 Agent”。

而是那个能够：

知道什么时候应该让 Agent 工作，什么时候应该改变方向，以及什么时候必须让它停下来。

这或许才是下一代 Software Factory Control Plane 真正要解决的问题。