JEV：软件工厂缺失的控制平面

梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace

编排正在成为基本要求。优势转向一个快速语义层，在工作进行中判断工作，以及决定下一步发生什么的确定性代码。

软件工厂正在擅长显而易见的部分：将大型软件目标转化为一系列代理工作。

规划和多代理编排正在改进。

云运行时正在改进，验证正在成为一等角色，而不是事后考虑。

高级软件工厂已经可以分离编排器、工作者和独立验证器：版本化基础设施，代理、触发器、模型、权限和检查点定义为代码。

这是真正的进步，但它也暴露了下一个瓶颈。

难题是从编排工作转向在工作发生时判断工作。

生产工厂不能停留在知道worker-7正在运行、PR存在或测试命令退出零。

它必须不断询问语义问题：

• 这个工作者是否仍在取得有用进展？
• 实现是否偏离了实际需求？
• 测试是有意义的，还是仅仅是绿色的？
• 此更改现在是否需要安全审查？
• 应该由不同的工作者负责下一步吗？
• 当前上下文是否足够？
• 任务是否已跨越人类应该接管的边界？

这些是控制平面问题。

有趣的新原语是一个模型，它可以足够便宜地回答许多小的语义问题，以坐在执行循环内部。

TypeSafe AI的Jev是其第一个"系统一"模型：状态和类型化问题输入，结构化概率答案输出。

其公共API公开三种问题类型：Noul（陈述为真的概率）、Choice（从固定列表中选择一个选项）和Score（沿有序级别对状态进行评分）。

每个问题都针对相同的状态独立、并行地评估。

这种形状给了软件工厂它们在很大程度上缺失的东西：一个快速的语义状态估计器。

1、编排正在成为基础层

今天的工厂架构已经在向可识别的堆栈收敛。

你可以将大型目标分解为特性和里程碑，用专注的工作者执行它们，并在里程碑之间插入新的验证器：工厂即代码、多个代理角色、云执行、集成、可观测性、评估和人工干预。

你还可以提供服务、所有者、部署、事件、策略和其他工程实体的建模图，供代理和工作流使用。

这些系统解决了大量的工程问题。

但一旦每个认真的平台都可以启动工作者、持久化状态、路由任务和插入审批，这些原语就不再是差异化因素。

控制平面成为有趣的部分：基于当前状态的含义决定下一步应该发生什么的逻辑。

想想Kubernetes，但使用语义状态而不是CPU和内存压力。

调度器可以确定性地看到进程是活动的，而语义控制器可以估计进程是活动的但没有进展。

2、架构模式：生成式工作者、语义监督者、确定性策略

这种架构最干净的版本有三层。

1. 生成式工作者做昂贵的、开放式的工作。它们检查代码、调用工具、修改文件、运行测试、读取日志，并推理故障。

2. 快速语义监督者估计状态。它消耗有界证据并返回概率或分类，如worker_stuck、tests_sufficient、requirements_satisfied或needs_human。

3. 确定性软件决定哪些操作是合法的。阈值、重试限制、预算、权限、审批要求和终止状态保持为普通代码。

不要要求模型同时推断工作者卡住并决定你的生产系统允许多少次重试。

第一个是模糊的，第二个是策略。

开源的Foreman项目是Josh Rasen的一个紧凑示例。

它在并发监督循环旁边运行Codex工作者。

当工作者继续进行软件工程工作时，Foreman收集有界的仓库和运行时证据，向Jev询问一组语义问题，并将结果概率输入Python策略。

工作者循环保持代理性，控制循环保持受限。

对于实时干预，Foreman使用Codex App Server的turn/steer方法，该方法向活动轮次附加输入而不启动新轮次；turn/interrupt提供取消路径。

类型化并不意味着正确。

一个完美类型化的worker_stuck = 0.91仍然可能是一个糟糕的判断。

该设计的价值在于不确定性保持可见，策略保持可检查。

3、高频语义控制解锁的内容

3.1 路由工作者，而不仅仅是模型

模型路由询问哪个LLM应该处理请求。软件工厂有一个更大的决策面。

• 此任务是否应该留在实现工作者手中？
• 是否应该移交给安全工作者？
• 最新的差异是否需要数据库专家？
• 验证应该是基于浏览器、基于测试还是手动的？

工作者路由可以不断重新评估，因为任务本身在执行过程中会更改。

一个开始时是前端问题的bug，一旦工作者找到根本原因，可能变成认证问题。

静态编排倾向于保留原始分配，语义控制平面可以从实时状态重新分类所有权。

3.2 检测进度，而不是活动

代理可观测性通常事件丰富但含义贫乏。

你可以记录每个工具调用、令牌、shell命令、补丁和测试结果，但仍然不知道代理是否正在收敛。

语义监督者可以将这些事件压缩成一个小的操作状态：进度、卡住、漂移、完成信心、验证需求等。

这给了工厂一个它实际上可以控制的信号。

3.3 在读取时路由上下文

上下文湖创造了另一个问题：丰富性。

一个成熟的组织可能有需求、架构文档、事件、所有权元数据、策略、PR历史、运行手册、依赖图和先前的代理跟踪。

将所有内容发送给每个工作者是昂贵的，而且通常有害。

相似性搜索只捕获一种相关性。

软件工作需要随任务变化的相关性："与此API实现相关"、"与安全审查相关"和"与此部署是否风险相关"是三个不同的检索函数。

快速分类器让框架在读取时派生相关性。

工作者或编排器指定当前选择标准，控制层对可用上下文进行分类，只有选定的切片进入昂贵模型的上下文。

缺失的部分是一个廉价的决策层，可以反复选择该图的哪部分现在重要。

3.4 添加护栏而不将代理变成工作流引擎

通常的安全权衡是不舒服的。

一端是刚性状态机，留给代理很少的自主权，另一端是长时间运行的代理循环，几乎在内部做出每个决策。

语义控制平面开辟了中间地带，让工作者探索但将持久检查点保持在代理外部。

在每个检查点，评估语义条件并决定是继续、引导、验证、停止还是升级。

工厂获得控制权而无需编写工作者整个轨迹的脚本。

3.5 持续执行语义策略

硬安全边界应该保持硬性。

权限、沙箱边界、网络控制、密钥访问和生产部署权限不应依赖于概率分类器。

但许多组织策略是语义的。

一个更改可能在技术上已授权但足够大以至于需要安全审查，或者工作者可能对仓库具有写入访问权限但开始触及预期范围之外的文件，常规依赖项升级可能意外修改受监管的数据路径。

语义模型不应执行策略。它应该产生确定性执行代码消耗的信号。

这种区别使模式可组合。

3.6 使人类升级动态化

大多数人在回路中的系统仍然严重依赖于预定的门。

运行时工作更混乱。

代理可以在工作流编写时没有人预料到的地方变得不确定。

控制平面可以持续估计工作是否仍在自主操作包络内。

人类参与成为另一个路由目的地，由当前状态触发，而不仅仅由静态审批节点触发。

4、快速开始：在本地运行Foreman

Foreman明确是一个实验，但它足够小，可以一次理解。

你需要Python 3.11+、设置了认证的Codex CLI，以及用于真实Jev运行的TypeSafe API密钥。

该仓库当前依赖于typesafe-sdk>=0.2.0并公开foreman CLI（pyproject.toml）。

git clone https://github.com/thruwire/foreman.git
cd foreman

python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install '.[dev]'

cp .env.example .env

对于真实运行，将你的密钥添加到.env：

TYPESAFE_API_KEY=your-key-here

然后认证Codex：

codex login
codex login status

从离线模拟开始：

foreman demo --repo .

然后将其指向一次性仓库：

foreman run \
  --repo ../example-service \
  --job "Add per-user API rate limiting and cover the failure paths with tests."

Foreman将本地运行状态持久化在.foreman/runs/<run-id>/下，并公开foreman runs和foreman inspect以供查看时间线。

5、Jev调用故意无聊

src/foreman/foreman/jev.py中的模型适配器构建一个类型化是/否问题的字典，并针对相同的观察评估它们。

一个精简版本如下所示：

questions = {
    name: Noul(instructions=instructions)
    for name, instructions in ASSESSMENT_QUESTIONS.items()
}

response = await client.system_one(
    state=observation.model_dump(mode="json"),
    questions=questions,
    model="jev-latest",
)

这种简单性是一个特性。

TypeSafe的Python SDK直接支持异步system_one(...)调用和结构化问题类型。

Foreman询问十个独立的问题，包括实现是否完成、测试是否充分、工作者是否卡住以及是否需要人工输入。

6、策略应该留在代码中

真正的控制逻辑位于src/foreman/policy.py中。

该仓库有意对决策进行排序，以便安全性和硬生命周期限制在生产力决策之前获胜。

简化形式：

if assessment.needs_human >= config.human_threshold:
    return ESCALATE

if worker_is_active and (off_track or stuck or policy_drift):
    return STEER_WORKER if steering_is_allowed else STOP_WORKER

if finish_ready and verification_resolved:
    return FINISH

if should_verify:
    return START_VERIFIER

即使你明天将Jev换成另一个分类器，我也会保留这一部分。

语义推断应该估计。确定性代码应该治理。

7、监督者必须是事件驱动的，而不是令牌驱动的

在每个stdout行上调用分类器将是浪费和嘈杂的。Foreman的运行时使用asyncio.Queue，合并工作者事件的突发，强制最小评估间隔，并让重要的生命周期事件绕过正常的去抖动（runtime.py）。

该模式比任何特定模型都重要。

在生产中，评估频率应该是一个控制系统参数。

你可能希望在故障、权限更改、大差异或重复工具调用后进行高频检查，而在稳定、长时间运行的工作期间进行低频检查。

最终，评估调度器本身变得自适应。

8、在信任生产之前我会添加的内容

语义分数尚未针对此用例进行校准，误报和漏报都很重要，V1一次运行一个编码工作者，本地执行不是隔离边界，持久性是为检查而不是生产耐用性而设计的。

生产实现应该快速添加四件事。

• 校准数据集。存储观察、语义分数、选择的操作、人工覆盖和最终结果。从你自己的工厂历史而不是直觉调整阈值。
• 决策评估。分别评估控制器和工作者。"实现代理是否解决了bug？"和"监督者是否在正确的时间干预？"是不同的基准。
• 迟滞和时间特征。一个糟糕的分数很少应该杀死一个工作者。使用趋势、宽限期、重复评估和先前干预来避免振荡。
• 严格的权限边界。语义决策可以请求转换。它们应该永远不要绕过沙箱、IAM、分支保护、部署审批或其他确定性控制。

9、持久护城河是决策历史

前沿模型将不断变化。

代理框架将不断变化。编排器将收敛于相同的明显原语。

变得组织特定的是由数百万个小决策构建的控制策略：何时重试、何时重新路由、哪些上下文重要、验证何时值得成本、哪些信号预测失败以及人工干预何时实际改善了结果。

数据复合。

运行与其他人相同编码模型的工厂，如果它具有更好的语义状态估计器、更好的策略阈值、更好的上下文选择和更好的反馈循环，仍然可以表现得非常不同。

这就是为什么我认为下一代软件工厂看起来不太像更大的代理群，而更像更好的工业控制系统。

工作者将变得更加智能，差异化将是知道何时让他们工作、何时重定向他们以及何时停止他们的系统。

原文链接：JEV is Missing Control Plane for Software Factories

汇智网翻译整理，转载请标明出处