同一个模型，30 分和 95 分的差距不在权重，而在 Harness

InfoQ 中文 2026-11-04T09:40:22.969503

同一个模型权重，换一套 Harness（套在模型外面的运行框架），ARC-AGI 成绩能从 30% 提升到 95% 甚至 100%。YC Paper Club 的 Harness Night 专场上，三位研究者从表达力、硬件边界、组织落地三个角度说明：Harness 不是“包装纸”，而是决定模型能做什么的关键一层。

被低估的“包装纸”

“Harness 就是包装纸、脚手架、提示工程。”这类说法在 Reddit 上隔几天就会出现一次，甚至有人断言“上下文工程根本不算研究问题”。但现实是：同一份模型权重，换一套 Harness，ARC-AGI 的成绩可以从 30% 直接上升到 95% 甚至 100%。

在 YC Paper Club 的 Harness Night 专场上，主持人、VC Visiting Partner Francois Chaubard 与几位论文作者展开讨论：Prime Agent 作者 Seth Karten、OpenJarvis 作者 Jon Saad-Falcon，以及 QM 团队的 Josh France 和 Regan Bell。三场演讲连起来是一条线：Seth 讲 Harness 该具备什么样的表达力，Jon 讲这套东西能跑在怎样的硬件边界内，Josh 和 Regan 讲把它放进真实组织后，权限、信任和协作会最先暴露问题。本文基于该活动视频整理，经 InfoQ 编辑。

三位讲者的核心观点如下。

Seth Karten：Harness 的表达力从哪来

Seth 主张回到第一性原理：先搞清楚 Harness 到底是什么、该怎么建。

Jon Saad-Falcon：把个人 AI 从云端拿回来

Jon 的出发点是：个人 AI 不该困在云端。

Josh France 与 Regan Bell：真实组织里踩出来的三条经验

QM 是给 YC 每位员工配备的类 Claw 助手，Slack 或 Web 都能用，具备个人上下文、沙盒文件和定时任务，支持多人协作；覆盖邮件分类、法务财务流程、文档编辑、内部取数，以及启动内部 Web 应用。Josh 和 Regan 从三次迭代的经验教训里，反推出一个 Agent Harness 应该长什么样。

为什么 Harness 值得被当成研究问题

Francois Chaubard：为什么是 Harness？它不就是个包装、脚手架、提示工程吗？一个月前有条 Reddit 帖子说：“不确定这种提示工程配不配得上顶级机器学习会议。”还有一条很经典：“上下文工程不是研究问题。”Harness 长期以来被贬低为不入流的研究。但它带来了 18% 的提升，这是 Harness 1 和 Harness 2 之间的差距；也正如 Seth 会讲到的，这决定了 ARC-AGI 能不能跑通，所以它显然值得研究。

看这张经典的图：横轴是发布时间，纵轴是 Agent 能持续运行的时间。你会发现很多进步都归功于 Harness。我把它叫“静态 Harness 时代”，因为 Harness 本身不自我改进。而最近六个月，所有进展都集中在自我改进的 Harness 上。

这张图来自 Trajectory CEO 的演示。他讲的是，我们一直测的 perplexity 和智能有一定相关性，于是不断把智能往上推，却没有把测试时经验用好。我们在新领域积累了大量测试时经验，却不能快速适应。很早大家就知道，在线样本增加时，怎么真正做到 batch size 为 1 的学习？没有这样的结构。ICL 到 40 到 50 个样本就饱和，验证集上不再提升，接着就要上小秩 LoRA、大秩 LoRA、SFT。居然有这么多不同的训练流程，这很奇怪，而这正是 Harness 能大显身手的地方。

ARC-AGI 揭示的核心，是适应新问题、新分布的速度。这些游戏背后投入了大量思考，确保游戏一到游戏二考的是正交技能，这样才能隔离出流体智力。Claude Opus 是最早在私有保留集上被验证的模型之一，只有 Greg 和 Chalet 能访问，最好成绩是 30%。而仅仅靠 Harness——这个曾被认为不值得研究的包装和脚手架——我们能到 95%，Nvidia 的 AVO 到了 100%，Prime Agent 和 Nvidia 都是最近刚出的。

还有一件事。Karpathy 三月推出 auto researcher，我 fork 之后本来只想做个小界面看进度，结果意外构建了一个 Harness。它的工作方式是：你指定一个目标。我给的例子是“扩散 LM 打不过自回归 LM”，但如果做集成，把扩散 LM 分片成多个实例，因为它的每 GPU 算术强度比 AR 高得多，分片后总体上可能更好。

我把目标交给 Agent 群，给一些种子想法：改变集成大小，分片 100 次、10 次、5 次。再指定验证指标，比如 GSMAK 加 GPT2 的设置。然后 scoping Agent 去查论文和 GitHub 仓库，交给叫 Chris Ray 的 PI Agent，再交给叫 John South Khan 的研究 Agent，他去找 council，我和 Yaso 给反馈，Chris Ray 每小时催一次，最后进 author Agent，冻结想法、写消融实验、写论文。

它现在真的在发论文，我读过，写得不错。三、四月还很差，五月就好多了。现在我把八个想法交给八台 H100 节点，每台八张卡，就不管了，时不时检查一下收论文。真正变的是加在上面的 Harness，我没花多少时间，但这基本就是我做研究的方式。

我花了个周末读了一批经典文献，做个五分钟的历史回顾。不按时间顺序，也会跳过很多论文。

最初的 Harness 就是 GPT-2，2019 年 2 月，一个 while 循环加 end-of-sequence 判断，加上 top-P 采样和环境，没了。没有工具调用，没有技能，这就是 V0 版本。拿 GSMAK 举例：系统提示设定你是数学老师，上下文是“Susie 有五块钱，她花了三块，她现在有多少？”，没有 chain of thought，就是四个井号加两个 end-of-state 加 end-of-sequence，我们测四个井号之后的准确率。

之后六年一直在给静态 Harness 加功能。把一堆例子放回上下文，这就是 2020 年 7 月的 few-shot learners。然后 chain of thought，与其直接预测“井号井号 2”，不如把计算分散到更多 token 上。这些都是上下文、输出空间和动作空间的创新。然后是 WebGPT 和 Toolformer，给它工具，它可以调用。做减法时不用在权重里算 5 减 2，直接调 Python 的 sub 函数。这很酷，你可以在系统提示里暴露所有工具，工具就是这么来的。

然后 MemGPT，最酷的工具之一是能读写自己的上下文。在那之前只能不断追加，现在给它对上下文的增删改查权限，把一小块叫“记忆”。Voyager 再进一步：工具能串联完成任务，但学会了之后怎么提炼回系统提示让它永远记住？这就是“技能”，他们在 Minecraft 里做的，到现在还是技能的定义。InterCode 是动作空间创新，直接输出代码就等于即时生成工具或技能。ReAct 先出来，然后 self-refine、reflection，思路是我有多个不同角色的 Agent，在上下文层面互相帮助自我改进。比如我把 3 和 5 弄反了，发给内部评估器问“这样对吗”，回答是“不对，看起来不对”，reflection 说“你把这两个弄反了，回去改一下”，这是最早的多 Agent 想法。

再往后，一个工具就能生成子 Agent，它们存在持久循环里，我可以调用，也可以不断加新的。RLM 更疯狂，递归调用 RLM query 解决更大类别的问题。这就是 Harness v1 版本，整个都是静态的，我没有改进系统提示，也没更新 Harness 本身。

让 Harness 自己进化：从改提示词到改代码

先回顾一下 V1 的构成：一份 Agent 规范加系统提示，规定允许几轮对话、多少次工具调用，列出可用的工具、技能和子 Agent，然后放进循环里跑。它既能被 Slack 里的消息触发（后面会讲到的 QM 就是，我每天都在用），也能挂在 cron 上，每小时醒来干点活。再配上会话管理、循环和上下文编译，整套流程就是：把所有东西塞进一次语言模型调用，拿回动作，调工具，再把结果追加回上下文。

真正让人兴奋的方向，是让 Harness 自己学习：要么学系统提示，要么直接学 Harness 本身。

大会现场就能碰到 Continual Harness 论文的主要作者，值得当面聊一聊。

Prime Agent：把 Harness 当成 Agent 的操作系统来设计

Seth Karten 的观点是：应该用第一性原理重新思考 Harness 该怎么造。

原始的大模型就是个顺序处理器——权重固定、上下文可见、token 进 token 出。今天我们不再这样看它：它有一组可以访问的文件，有无穷的程序和工具可用，甚至能给其他模型的会话发消息、创建子 Agent，但底层依然是 token 进 token 出。Harness 就是夹在模型和世界之间的那一层，由持久状态、工具和计算三部分组成。

从使用者视角看，打开 Prime Agent 就像打开 Claude Code、Codex 或 Cursor：进入 Agent 视图，先看到所有并行会话的概览，点进去是根会话，它扮演所有子 Agent 的项目编排器。你不需要命令它启动子 Agent，它觉得有用就会自己开。所有调用都是编程式的，因为整个系统建立在递归语言模型之上——工具、记忆、子 Agent 全都跑在 IPython shell 里。

每个 Agent 背后是一个持久守护进程：你合上笔记本，或者按 Ctrl-C 退出，它依然在后台跑，必须显式停止。系统还借鉴了 Continual Harness 的实时增删改查能力，用来管理记忆、技能和子 Agent，并且能持久地修改自己的系统提示。

把上下文分成 L1、L2、L3，像一层层缓存

最容易获取的信息是模型权重，但把所有东西都塞进权重，意味着每次更新都要微调，成本太高。

于是有了活跃的输入上下文，用上下文示例增强能力，但它迟早会被用完。最早的 Harness 形态就是压缩：让 Agent 总结自己的历史，从而突破上下文窗口的限制。

一旦超出模型直接的输入输出，就进入了 L2 和 L3。L3 更像调度状态，比如文件系统，从「主内存」读写。L2 介于活跃上下文和文件系统之间：你有一个实时的 REPL（交互式解释器），就像 Jupyter 里的 IPython shell，变量都在内存中，Agent 可以编程式地操作它、在上面跑程序，省下大量 token；也可以创建子 Agent 来节省上下文。

压缩让上下文随时间不断更新，但超过一定层级，就得考虑如何更新。这就是增删改查要解决的问题：怎么超越简单的创建和读取，做到随时更新和删除状态。REPL 可以看作 Agent 侧的垃圾回收——清理变量、决定哪些子 Agent 可用，免得内存把笔记本撑爆。再往上是精炼（refinement）：更新和删除系统里的技能、记忆和提示词，免得硬盘被占满。

从图灵机到冯·诺依曼机

还有一个我喜欢的类比：原始的大模型更像图灵机——一条纸带，指令进去，操作完输出。Harness 更像冯·诺依曼计算机，可以在外部内存上读写，因此更强大，能处理更广泛的问题。

那怎么构建一个好的 Harness？答案是尽可能提高表达力。早期的 Harness 非常具体，把计划、行动、批评拆成固定步骤，但这些能力现在的模型原生就会，不需要再显式强加一个 ReAct 循环。模型做不到的，是那些需要表达力支撑的事：压缩、用 Python REPL 跑程序、以编程方式创建子 Agent、访问状态、以及多样化的反馈机制。这些表达能力每移除一项，就等于移除了一项模型无法用别的方式完成的能力。

我的合著者 Alex 的 RLM 论文，你们可能读过。我们的扩展，是把子 Agent 做成持久子会话：父会话创建并启动 RLM 子 Agent；子 Agent 跑完任务、报告最终状态后进入空闲，但仍留在内存里。父会话随时可以发消息让它继续，它之前积累的上下文还在，不会丢。我们也不想占太多内存，所以可以把它卸载到非活动状态，需要时再发消息唤醒。

Continual Harness 来自我之前的一篇论文，讨论的是把整个 Harness 状态编码下来。我们想把这种能力开放给 Agent，让它根据全部历史去更新未来的 Harness 应该是什么样：系统提示要不要改？要不要新建技能？我理解的技能，是实现某个目标的一组指令或程序；记忆则是对重要事项的长期存储，另外还有持久存在的子 Agent 规格。有些子 Agent 的上下文很有用，以后还想复用。这种反思和 refinement 的能力对模型非常强，它们现在还不擅长，但在构建 Harness 时就应该让它比当前模型略强一点。这样你就能拿到推理轨迹，推动下一轮模型迭代，模型也能处理 Harness，把自己引导到更高性能。

Prime Agent 里我最喜欢的功能之一，从第一版就有：任意两个 Agent 之间可以发消息。我一直在找管理自己所有 Agent 的最好办法——它们每天在五个方向、五十亿个不同方向上替我做事，如果它们能直接互相留联系方式、自己协调，那就好太多了。事实证明，这对软件工程和长周期任务也非常有用。

设计 Harness 时，我们考虑了长周期性能。我想跑一些任务，不用一直盯着，回来再检查进展。很多评估缺的就是这个视角：如果一个模型跑的时间不够长，或者预算用完就停，而另一个模型用更多预算继续干，你既没有在相同支出下比较，也把性能藏起来了。我想看到真正的平台期——投入更多测试时 token 后，性能从哪个点开始只剩增量提升。

接下来我会讲我们怎么做 Prime Agent，测试时扩展和结果，看看信息管理对 REPL 处理长上下文是不是真的有用，以及在持续一周以上的超长周期任务里，refinement 过程实际发生了什么。

这个 ARC-AGI 结果你们可能见过。我补了一个原始结果里没有的数据点，方便在不同 Harness 之间比较。我们想找一个大家关心的评估，就选了 ARC-AGI。我记得之前用 Continual Harness 加 Gemini Flash 拿到过 20%，所以觉得至少能有 20%。结果，我们的通用 Harness 根本没为 ARC-AGI 设计，却表现得很好。

我在网上找到一个叫 Prolong 的社区排行榜，直接把他们的系统提示词扔进 Prime Agent，第一次跑就 99.9%。然后我看日志，发现自己在作弊。于是老老实实做沙盒隔离，又花了一天。回来用 GPT-5.6 Sol 拿到 78%，我觉得这是个很棒的结果。

提示词很通用：用世界模型解 ARC-AGI-3，列出你可以采取的行动，再加上 Prime Agent 的通用系统提示——你有 REPL，可以调用子 Agent。我翻了轨迹，它在做各种编码调用、检查场景、分析图像、做图像处理，看起来是在利用 REPL 做合理推理。然后我们跑了 GPT-5.6 Terra，25.7%，相对前一周的结果已经很好，超过了 GPT-5.6 Sol 的一些高配版本。跑 Opus 是 95.5%。

我们也和其他 Harness 比过。有人问我用 Claude Code 跑过吗？跑过，结果不好，所以我直接引用了 Claude Code 的原始结果；后来别人用类似 Prime Agent 的配置跑出了更好的成绩。有意思的是，很多很流行的 Harness，在 Prime Agent 表现好的地方不一定表现好。比如 Hermes Agent，很快就花掉很多钱，我花了五千美元也没什么性能提升，只能中断。不是说这是他们的上限，但成本确实高。成本性能比很重要，能省钱的一个办法就是编程式地处理上下文。

长周期评估我们跑了 Oolong 和一些编码类的 Emulator Bench。它很快发布，是 Program Bench 的替代品。结果主要是持平或略好，比如用 GLM-5.2 到 Opus 5 和 GPT-5.6 Sol，跟 Pimono、Claude Code 之类比较。Emulator Bench 是复现整个计算机系统的模拟器，比如做一个 Game Boy Color。因为它有 REPL 和 RLM，能在提交最终方案前用这些程序做实验、做循环设计，更自由地试各种方案。GPU 内核也试了，不同模型上大致持平，一个更好一个更差；我们没有过拟合任何单一评估。

长周期任务上，Agent 会自动做“循环外实验”，先在小成本环境里试错，再决定要不要花昂贵的 GPU 时间；7 天工厂运行中 633 个 Agent 输出 2300 万 Token 仍未卡死。另一条线是 OpenJarvis：把推理、Agent 执行、记忆、学习这些原本依赖云端的部分搬到设备端，在保住隐私和质量的前提下把成本压了下来。

长周期任务：让 Agent 自己去跑实验

长周期这一侧，我们还试了自动研究：基于 NanoGPT Speedrun 做扩展，给 Agent 8 块 H200，连续跑一周。

你可能觉得 Prime Agent 会好得多，因为它能写代码。但这类任务方差很大，很难判断提升究竟来自 Harness（模型外层的运行框架与脚手架）还是模型本身。

不过我们观察到，较新的模型——DeepSeek-V4、GLM-5.3、Kim K3——会做我们所说的“循环外实验”：先在 CPU 上跑小实验、观察参数化情况、做超参搜索、分析数据，而不是把所有时间都砸在昂贵的 H200 实验上。它们跑的不是主实验，而是为了优化主实验。这说明我们塑造表达性功能的方向是对的。这类模型擅长自动研究，如果有“人在回路”（Human in the Loop）配合引导，效果会更好。

7 天工厂运行：633 个 Agent，2300 万 Token

最后我们做了一次为期 7 天的“工厂”运行：633 个 Agent，输出 2300 万 Token，目标是在科技树上持续取得进展。子 Agent 分工做研究、建造、收集资源，还能通过 refinement 机制借鉴过去的经验，在超长上下文里不至于卡住。最有趣的是它一直没卡住，到阶段结束仍在推进——有点像 Gemini 玩 Pokemon 时给人的那种感觉。

如果只记一件事：去想想 Agentic 上下文管理，想想群体智能，深入研究 RLM（递归语言模型），并把评估标准化。

OpenJarvis：把个人 AI 从云端拉回自己的电脑

Jon Saad-Falcon 的判断是：个人 AI 的概念无处不在，但今天基本困在云端。很多 Harness 和项目能帮人做日常写作、研究、编码、日程管理，但像 OpenClaw、Hermes Agent 这类项目，大部分智能工作和查询仍然依赖云端 LLM。代价有四条：

本地 LLM 终于够好了。今天的本地模型只比前沿模型落后 6 到 12 个月，比如 Qwen 3.8 27B 大致相当于 2025 年 8 月的 Claude 4.6 Opus。加上笔记本和工作站的加速器越来越好——这周苹果刚发布新的 Mac Mini，苹果和 Nvidia 都在重新聚焦个人使用场景的加速器——这个差距还在缩小。

我们要探索的核心问题是：能不能把个人 AI 栈的核心部分——推理、Agent 执行、记忆、学习——完全放在设备端跑，同时保持和纯云端栈相当的竞争力。于是有了 OpenJarvis。我们想知道，在保证安全、隐私和质量的前提下，设备端免费能跑多少功能。为此定义了一组最简单的原语：

展示层面，我们用的是人们已经习惯的界面：桌面端照常运行，但能看到省了多少钱和多少能源；也能跑各种持续 Agent，以 cron 任务的形式日复一日执行标准协议。目标是和现有工作流即插即用，让人们第一次体验设备端 LLM，就像当年第一次用 ChatGPT 或 Claude。

优化思路上，我们尽量不干扰 LLM，只写一份覆盖这五个原语的简单规格，让它们按规格自我优化。跑完整个优化循环后，成本下降、延迟下降和质量提升同时出现。这个配置正好覆盖人们构建 LLM Harness 时最关心的五个方面：智能、引擎、Agent 逻辑、工具或学习系统，以及整体优化。

还有一件我觉得有意思的事：让云端 LLM 去手动和自动优化整个本地栈。也就是用云端模型的能力来诊断、提议、门控改动，为本地 LLM 生成改进方案，但真正部署做推理时不产生云端成本。我们发现，经过 Claude 或 ChatGPT 优化的 OpenJarvis 配置，比开箱直接部署有效得多，因为你可以针对不同工作负载定制具体的 LLM 和 Harness。

结果是，即使在个人 AI、个人使用、编码和 Agent 这些不同工作流里，用今天的端侧模型我们也能和云端模型一较高下。还有很多任务本地模型做不了，但随着模型被更好地蒸馏、加速器更好，差距每个月都在惊人地缩小。即使用今天的模型，我们也做到了 800 倍的成本降低，同时显著减少延迟。而且不管选哪个云端模型来做优化都有用：Opus 系列、Opus 5 和 GPT-5.6 Sol 自然最好，但 Gemini、Kimi、GLM 这些更大的模型家族也可以。

对开发者来说，这里有两个可迁移的经验：一是把“优化”当成一个可离线完成的环节，用强模型改配置、用弱模型跑推理；二是把本地栈拆成少数几个明确原语，才谈得上系统性地调优，而不是零散地换模型、换工具。

Josh France 介绍了 YC 内部开源 Agent Harness——QM 的演进过程。QM 为 YC 每位员工提供类似 Claw 的助手，可通过 Slack 或 Web 界面使用，每人拥有独立的个人上下文、沙盒文件和定时任务，也能在 Slack 频道这类多人在线环境中协作。用途覆盖邮件分类、法律与财务工作流自动化、文档编辑、从内部数据库取数，甚至启动实时内部 Web 应用（比如规划活动）。

这条路线是多个内部 Agent 项目逐步叠加的结果，每一个都赶上了模型能力提升的红利：

于是 4 月的问题变成：能不能不给每人买一台 Mac Mini，也能让每位员工拥有这种体验？最终配出了一个 50 多台虚拟机 Hermes Agent 的集群。它们很有帮助，但需要大量配置，管理起来本质上非常困难，有点像打地鼠——得进去一个个修。于是目标清晰了：构建一个系统，解决大集群的缺点，同时保住个性化和人们真正认可的部分。

从「把 Agent 关进沙盒」到「把大脑抽出来」

Regan Bell 补充了另一条线索。模型在指数级改进，给它更多能力，回报也越来越可观——OpenClaw 给 Agent 一台自己的电脑，回报惊人。5 月团队开始思考：沿这条线还能推多远？他们喜欢「解除束缚」这个视角。2024 年前后《情境意识》那会儿，测试时计算刚开始成为现实，第一次给 Agent 工具时就有种直觉：模型里蕴含的智能，比我们实际用到的多。如果能大胆突破给 Agent 的能力边界，魔法就可能发生。

QM 的第一件事，是把系统的大脑从沙盒里抽出来。用 Hermes 和 OpenClaw 时，Agent 拥有自己的电脑，能力很强，但也被困在那台电脑里——哪怕只有几十个实例，管理几乎立刻变得难以驾驭，所有会话都困在本地、彼此孤立。QM 把所有东西卸载到 Postgres：全部集中化，包括与 Agent 的所有对话，再把这些聚合上下文暴露给 Agent 本身，让它能看到整体。另一件事是改变沙盒的定位——不再把它当作 Agent「居住的家」，而是它能按需取用的资源，限制少得多。

这也带来一个新可能：你会积累一个大型评估集，包含人们与 Agent 对话的全部轨迹，原则上可以做爬山式优化，形成自动改进循环。团队在这件事上结果好坏参半。如果放大量 Agent 去修它们遇到的所有 bug，用 LLM 当评判，会出现「主角综合症」——每次修复只看到大象的一部分，看不到整个系统。所以 Human-in-the-Loop 一直很重要，尽管团队期待它最终能完全自动化。

另一项主要工作，是把 Agent 接到公司里所有能接的资源上。YC 恰好已经有一个连接了很多系统的 CLI，不在这套 CLI 里的就允许加任意 API 密钥。团队还希望员工笔记本上具备同等能力，比如通过设备码 OAuth 导入钥匙串再刷新，尽量模拟人在电脑上的操作体验。数据库主要保持只读，写入走人工审核的批量更新：Agent 提出编辑计划，人快速过一遍，确认没有离谱操作再执行。他们观察到已经开始有点机械性批准了——就像早期用 Claude Code 会仔细审查工具调用，慢慢就建立起信任。这是接下来几个月要持续关注的事。

沙盒是资源，不是“家”

在 QM 的设计里，沙盒是 Agent 可以调用的资源，并不充当它固定的住所。默认情况下，系统会把分配给当前对话用户的那个沙盒交给 Agent；也有一些环境允许 Agent 聚集在一起协作。要跑重型开发负载，Agent 可以申请一台资源更多的机器；处理简单任务时，则挑性能低一点的沙盒。把“用哪台”的决定权交给 Agent 而不是 Harness，这一点很关键。

同样，允许 Agent 接入自己的运行时、自己选择模型提供商，也能摆脱一些限制。比如用 Fable 时，你可能遇到过这种情况：想做 AI 研究或网络安全，却不断被拒绝，这时 Agent 可以切换到另一个模型。在不同沙盒提供商之间切换也常常有用。

一般原则是 Harness 要尽量精简，核心只有三个工具：在远程沙盒中执行命令、从对象存储读写、发布内部应用——后者是一个基于 Git 的简单系统。记忆、定时任务这些工具属于临时补充，用来填补系统里粗糙的边缘。

还没到 AGI：过早放弃与社交情境

目标是把 Harness 做成面向 AGI 的预判性运行框架，但还没到那一步，所以实际问题不少。

一是 Agent 处在很强的环境里、手上有所有工具，却经常过早放弃。过去一个月我们在实验“磨砺工具”：给目标设定预算，如果实际投入时间没到几个小时、或者 Token 消耗没到一定量，就不允许放弃。这样能得到更好的研究输出和报告。OpenAI 和 Anthropic 用非常类似的技术攻开放数学问题，这一现象很有意思；同样的方法对普通办公室工作也适用。

另一个常见问题是协作。Harness 要支持多人协作和 Slack，但受训练产物影响，即便系统提示里写得很清楚，Agent 仍然对自己的处境非常困惑，因此本地化的辅助手段很重要。

Josh France 补充了社交情境的问题：Agent 不理解信息该在什么场合分享。如果我告诉 Regan 一条信息，他凭直觉知道哪些场合能说；但要让 Agent 建立这种判断，需要实际做工作，否则特权信息很容易泄漏到不该出现的上下文里。因此，能放进 Agent“大脑”的信息，实际上受限于权限系统做得多好。YC 很幸运有多年积累的细粒度权限管理，但很多团队没有，需要在细微层面做知识共享的工作。

演讲视频原链接：https://www.youtube.com/watch?v=n9xKblqyQ28

关键要点

图片

查看原文