YC 研讨会：为什么 Harness 比模型更重要

核心结论（一句话）

模型决定潜在能力上限，Harness 决定能力能否在真实环境中持续执行、调用工具、保存状态、恢复失败并通过外部证据验收；因此 Agent 的工程竞争重点正在从“换更强模型”转向“构建更可靠的运行系统”。

分类提炼

知识节点

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点

  1. 反驳模型中心论。 节目把基础模型比作无状态的顺序处理器，认为上下文管理、工具路由、记忆、状态机、沙箱和恢复机制才是它连接真实世界的部分。模型变强会抬高上限，但不会自动提供持久进程、权限隔离、网络断点恢复和外部数据治理。
  2. 性能可能主要来自 Harness。 节目用 ARC-AGI 固定权重成绩提升、研究 Agent 自动跑实验和本地推理成本下降来说明外部运行环境的影响。它们适合作为“系统设计能改变结果”的案例，不适合作为已核验的通用能力或成本结论。
  3. Harness 有一条演化路线。 从固定系统提示和工具列表，逐步加入 few-shot、CoT、工具调用、记忆、技能、代码执行、反思、自我修正和递归多 Agent；最新方向是让系统能根据评测结果改写提示或调度代码。
  4. 研究自动化依赖持久执行环境。 节目描述的 PrimeAgent 类架构以根会话负责目标和调度，子 Agent 在隔离持久进程中执行代码、实验和写作；任务中断时计算容器可以替换，但状态和产物仍保留。
  5. 三层上下文减少浪费。 常驻模型能力、当前轮活跃上下文和外部文件/数据库/技能库不应混成一个巨大 Prompt。运行时可在 L2 中处理海量数据，只把高信号结果回填给模型，再把成功经验沉淀到 L3。
  6. 端侧与云端应分工。 节目提出用云端强模型“编译”特定任务的提示、工具协议和执行规范，再由本地模型重复执行，从而兼顾隐私、延迟和成本；收益依赖硬件、模型、任务和编译质量，不能直接套用节目数字。
  7. 企业多 Agent 首先要治理状态。 QM 案例的关键转向是把 Agent 的大脑/轨迹/产物从易失计算容器中分离出来，把容器当作可调度、可释放的计算资源，而不是永久住所。
  8. 三类反模式应默认禁止。 自由群聊会烧 Token 却没有产出；全公司文档一股脑注入会造成注意力和权限风险；相信模型自报成功会把残缺代码和错误数据传给下一步。生产系统应使用结构化事件、渐进上下文、最小权限、确定性检查和人工门禁。
  9. 工程投入建议。 节目建议选稳定且性价比高的主力模型，把主要工程精力投入结构化工具协议、代码沙箱、长周期序列化、可恢复调度和闭环评测，而不是每周追逐榜单。

备注与证据边界

相关链接