Pablo Zavala · AI 安全评估 · 研究工程

JROS：带收据的 Resource OS

JROS 把求职转化为受治理的资源工作：来源、主张、申请包、验证运行，以及人类审批门。

2026年7月6日 · 7 min

JROS 起源于一个很实际的约束：求职会产生太多小型主张，单靠记忆无法可靠管理。每个岗位都有来源、新鲜度、匹配论证、风险等级、隐私边界和决策成本。因此，难题不只是找到职位。真正的难题是在行动时保留证据、判断和控制。

JROS，即 Job Search Resource OS，是我对 NUDG 的 Resource OS 思路做的第一个真实 dogfood。这个系统把求职视为受治理的资源工作：来源、主张、申请包、验证运行、会话记录和审批门。目标是可检查的委托，而不是申请数量。

申请工作需要收据

申请自动化常常从错误指标开始。更多投递看起来像更多进展，于是系统容易奖励弱来源、过期岗位、通用材料和未经审查的外部动作。

JROS 使用更严格的标准。一个线索只有在系统能够回答这些问题后才有用：哪个官方来源支持该岗位，哪些事实支持匹配论证，哪些证据已经变旧，哪些字段需要私人或战略判断，哪项动作拥有委托权限，以及哪项动作必须停在人工审批处。

操作循环

操作循环保持刻意简单。首先，JROS 从配置来源和外部研究中发现线索。聚合器可以提出候选；公司或 ATS 官方页面负责验证。随后，系统给线索评分并路由，记录来源、公司、角色和验证状态，并准备一个说明我需要做出的具体决策的申请包。

接着，自治政策对动作分类。 `A0` 表示只做研究或草稿。 `A1` 表示在狭窄条件下准备常规投递。 `A2` 表示提交前请求批准。 `A3` 表示硬停止。由于敏感、战略和外部动作带有声誉成本，最终提交仍由人类控制，除非之后有明确授权指向具体动作。

最后，系统把结果写回账本。一次纠正成为新条目。一个过期岗位成为明确状态。一个阻塞点成为可复用教训。

材料日期与证据表面

本文的材料日期是 2026-07-06。一次截至该日期的本地 JROS 数据库查询返回 824 个资源、1,934 条来源、303 条主张、1,403 个实体、52,906 次验证运行和 7,129 条治理记录。2026-07-06 执行的文档审计通过，结果为 16,349 个文件、824 个资源、1,934 个来源、303 条主张和零个警告。

这些数字描述系统形状。JROS 是一个本地控制平面，用来支持有证据的行动。私人数据库继续保持私有；本文公开模式、边界和聚合数字。

审批边界承载产品

核心设计选择是审批边界。JROS 保持邮箱内容私有，不把截图放进公开证明，不修改公共资料，不发送消息，尊重安全控制，并把敏感回答路由给我。

系统可以准备、验证、起草、比较和总结。若某项动作会提交申请、发送消息、回答敏感字段或改变公开工件，系统就会停止。这个边界把流畅助手转化为受治理的工作者。

瓶颈发生了变化

早期 JROS 的问题是智能体能否找到足够多的可行岗位。到 2026-07-04 周度复盘时，线索供给已经健康。瓶颈转向决策压缩：同一公司的多个变体、申请包选择、敏感门槛和阅读负担。

因此，最有用的表面变成了决策驾驶舱：一个推荐动作、少量备选、证据链接和明确审批门。

JROS 给 NUDG 的教训

NUDG 关注受治理的智能体资源使用：提出、授权、执行、验证并留下收据。JROS 在一个有具体成本的领域测试这个思路：个人数据、声誉、时间、私人文件、外部表格和不可逆点击。

教训很小，也很强。一个有用的 Resource OS 首先让资源变得可读。系统命名来源，命名主张，命名审批门，命名人类决策，并记录执行。

检查才是测试

JROS 应该由检查来评估，而不是由信心来评估。最后的问题是：另一个智能体，或我本人，之后能否回答这些问题：哪个来源支持了动作，哪条主张支持了推荐，哪项验证通过、失败或需要复审，智能体拥有什么权限，系统在哪里停止，以及纠正后发生了什么变化。

当这些问题有答案时，系统保存了判断力。Resource OS 的重点正在这里：收据优先于动作和数量。

来源