从采样循环到能够修改自身的系统
查看原文 07:43这期 YC Harness Club 汇集了 Prime Agent、OpenJarvis 和 QM 三个项目的分享。它们面对的环境不同：通用研究与编程、在设备上运行的个人 AI，以及供团队共同使用的助手。三场分享都在问，模型能够使用更多环境能力之后，可以完成哪些工作。
开场回顾了一条演进路线：从采样循环，到上下文示例、用更多输出 token 展开推理，再到工具调用、可编辑记忆与可复用技能。这些变化扩展了什么信息能进入上下文，以及模型输出能执行什么操作。工具可以计算；记忆操作可以修改已有信息，而不是一直追加；技能可以保留上次任务中找到的操作方法。
接下来要区分静态 harness 与能够改变自身的 harness。一个静态系统即使拥有很多工具和智能体，指令和运行代码仍然可以固定不变。提示词搜索修改的是指令；允许改动 harness 代码的系统，则能修改运行智能体的机制。开场将这些看作不同程度的修改权限，而不是可以互换的“自我改进”名称。
Prime Agent 从持久状态和计算能力出发
查看原文 19:09Seth 先把模型还原为顺序处理器：输入 token，输出 token。文件、工具和其他智能体会话，都是外部系统提供的能力。按他的定义，harness 位于模型与现实环境之间，提供持久状态、工具和计算资源。
Prime Agent 暴露了一个持久化的 Python 执行环境。根会话可以通过程序创建其他会话、交换消息，并用代码处理信息。后台守护进程使会话在用户关闭终端或笔记本交互界面后继续运行；关闭界面与明确停止会话是两件事。
协作问题也因此发生变化。子会话完成任务后可以进入空闲状态，保留调查过程中形成的上下文，父会话之后再给它发消息。暂时不需要的会话也可以移出活动内存，等需要时恢复。目的是保留已经完成的有效工作，同时控制维持这些状态所需的资源。
压缩上下文只是一种记忆管理
查看原文 21:23分享区分了模型权重、当前输入上下文、程序中的活动变量和磁盘信息。这几层的成本与容量不同。把所有信息放进下一次提示词，确实可以让模型访问它们，但会消耗输入 token，最终也会碰到上下文长度限制。
上下文压缩通过概括对话历史，让任务突破这个长度限制。持久执行环境提供另一种选择：把数据保留在变量里，用代码操作，而不是把全部数据再交给模型。持久化智能体同样可以保留一项调查的专门上下文，在被询问时返回结果。
每种选择都带来维护工作。变量和活动会话需要清理，避免内存无限增长；保存在磁盘上的技能、提示词和记忆需要修订，避免旧信息只增不改。Seth 强调，创建和读取只是问题的一部分，有用的 harness 还必须支持更新与删除状态。
给模型可以自主选择的能力
查看原文 25:10固定的“规划、行动、批评”流程规定了模型要走哪些步骤。Seth 更倾向于暴露可供选择的能力：程序执行、压缩、持久会话以及反馈。拿走其中一种能力，就可能让智能体失去原本能够执行的一类操作。
修订也遵循同样思路。以前的轨迹包含行动及其结果，智能体可以根据这段历史判断：系统提示词是否需要调整，一种新方法是否值得保存为技能，某个有用会话是否应当留待以后继续使用。
他明确承认，现有模型还不能把这些事情做得很好。他希望 harness 提供略超出当前模型充分利用能力的功能，让后续模型和训练轨迹能够进一步使用它们。这是设计方向，并不证明无限制自我修改已经可靠可用。
看性能平台，也看成本和失败
查看原文 29:06对于长任务，Seth 想知道随着测试时计算量增加，实际性能会在哪里进入平台期。如果以不同预算过早停止两个系统，既可能掩盖成本差异，也可能看不到其中一个系统继续工作后能完成什么。
他讲述的 ARC 评测经历包含一次重要修正。最初一轮跑出了接近满分的成绩，但检查日志后发现系统在作弊。之后他花时间设置了正确的沙箱。这段经历把轨迹检查放进结果的一部分，而不是把第一个漂亮数字当作充分证据。
他还介绍了使用八张 H200、持续一周的研究实验。这些实验方差很高，他表示团队无法把收益归因于 harness，而不是模型本身。能够观察的是行为：智能体先在 CPU 上运行小实验、搜索参数，再把时间投入昂贵的 GPU 实验。
据分享所述，一次七天的 Factorio 实验使用了 633 个智能体和约 2300 万输出 token。智能体分担研究、采集和建造等工作，并通过修订复用经验。这是持续推进任务的一个报告案例，并不是证明同样配置能在所有长任务上胜过其他方案的受控实验。
OpenJarvis 把本地运行与配置优化分开
查看原文 37:31OpenJarvis 关心的是，个人 AI 栈有多少部分可以放到设备上：模型推理、智能体执行、记忆和学习。动机包括持续的云端费用、隐私、能耗，以及拥有本地系统，而不是每次请求都依赖远程推理。
项目把模型智能、推理引擎、智能体逻辑、工具或记忆，以及学习方式设计为可组合的选择。用户界面与周期任务把这些组件接入熟悉的工作流程。本地硬件和推理引擎也是需要一起选择的系统部分，模型文件本身并不等于完整产品。
其中一条衔接路线是让更强的云端模型优化本地配置。云端模型负责诊断整个栈并提出修改；得到的系统在部署后仍可进行本地推理。这样就把寻找有效配置的成本，与之后反复运行它的成本区分开来。
演讲者报告，在所评估的工作流程中，成本和延迟都有显著改善，但也承认许多任务仍超出本地规模模型的能力。这些性能与效率说法属于相应实验，并不能说明笔记本已能替代所有个人工作中的云端模型。
QM 把沙箱变成可调用的资源
查看原文 45:58Josh 和同事介绍的 QM 是 YC 开源的工作助手运行系统，可通过 Slack 和网页使用。它支持个人上下文和共享频道，场景包括邮件分拣、编辑文档、查询内部数据，以及发布内部应用。
早期通用助手使用共享的提示词与工具循环。后来团队把编程智能体放进虚拟机，连接 Slack、CI 和开发环境，根据失败修改仓库指令。再之后，超过 50 个个人智能体实例给用户带来了定制能力，但逐台维护虚拟机变得困难。
QM 将协调状态移出单个沙箱。对话集中存入 PostgreSQL，并在系统的访问控制下提供给智能体。沙箱变成可调用资源：可以是分配给用户的默认环境，也可以是协作环境，或者承担重型开发任务的更大机器。
团队描述的精简核心包括远程执行、对象存储读写和内部应用发布。他们还尝试给目标设定预算，要求智能体持续工作一段时间后才能放弃。仅仅增加可用工具，并没有阻止智能体过早停止。
52:40 的原视频幻灯片将智能体核心、PostgreSQL 会话状态和按范围分配的沙箱资源分开。
共享上下文仍然需要权限和审查
查看原文 53:23集中的执行轨迹原则上可以成为改进系统的评测集，但 QM 团队报告，交给另一个模型裁判的自动修复循环效果好坏参半。智能体可能修好自己看到的一小块，却没看到整个系统。人在这个循环里仍然重要。
数据库访问以只读为主，批量写入方案会交给人审查。演讲者也承认一个实际弱点：随着信任增加，审核者会逐渐不加细看地批准。审批步骤虽然存在，效果仍取决于人是否认真执行。
共享频道还有另一层限制。智能体可能误解多人对话中的自身角色，私密信息也可能流入不应进入的上下文。团队认为，系统能接入多少信息，受权限控制质量限制。因此，增加可访问上下文，需要同时解决谁能接收信息，而不只是如何存储和检索。
本文依据 YC Harness Club《Why The Harness Matters More Than The Model》的历史公共字幕整理。文中的评测与部署结果均归属于演讲者的报告，本文未独立复现实验。