探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐

概览

本期围绕 Agent Harness 展开，核心问题是：当大家说“Agent 的上限由 Harness 决定”时，究竟在讨论什么。来新璐把 Harness 概括为“模型以外的部分”，包括执行能力、上下文/状态环境，以及多 Agent 的治理和编排。

讨论以 Claude Code 源代码泄漏为切入口，把 Claude Code 视为学习 Agent Harness 的样本，重点分析了工具、记忆、压缩、上下文交接、权限治理、CLI 与 MCP、沙箱等工程实践。

嘉宾的主要判断是：模型仍然是 Agent 智力的第一来源，但好的 Harness 要贴合模型运行逻辑，并且不能在模型变强后反而束缚模型。相比传统 prompt node / flow 的框架，他更推崇“模型即 Agent”“更多上下文、更少控制”“Bash/CLI is all you need”的方向。

节目后半段转向创业和未来判断，讨论了 Agent infra、混合组网、Agent payment、个性化模型训练，以及“零人公司”和 Agent 作为未来经济主体的可能性。

分段落总结

[00:00] 开场与节目目标

[事实] 主持人指出，最近大家都在讨论 Agent Harness，并提出问题：当我们聊 Harness 时到底在聊什么。

[事实] 节目将 Claude Code 源代码泄漏视为一个观察 Agent Harness 关键模块的教学样本。

[事实] 嘉宾来新璐是 Share AI 创始人，团队做了 Learn Claude Code 教程，用来解析 Claude Code 的 Agent 设计模式。

[事实] 本期目标是让听众理解 Harness 不是神秘概念，而是软件工程方法。

[01:44] Harness 的基本定义

[事实] 来新璐用一句话定义 Harness：“模型以外都是 Harness”。

[事实] 他把模型比作聪明的大脑，但如果没有身体和手脚，大脑只能思考，不能行动。

[事实] 他部分认可“Agent 的上限来自 Harness 设计”，但强调 Agent 智力上限仍然来自模型发展。

[推测] 在他的框架里，模型决定“会不会想”，Harness 决定“能不能做、怎么持续做”。

[02:45] Learn Claude Code 与范式争论

[事实] Learn Claude Code 大约从九个月前开始做，初衷是把 Claude Code 当作强大的 Agent Harness 样本来学习。

[事实] 嘉宾认为，过去 LangChain、LangGraph 等基于 prompt node、parameter flow 的方式，在未来 Agent 开发中会越来越不适用。

[事实] 他更看好 Agent native 的方式，也就是“Agent 即模型、模型即 Agent”，以及类似“Bash is all you need”的范式。

[推测] 这段讨论的核心冲突是：工程师到底应该控制流程，还是给模型足够上下文和工具，让模型自主完成任务。

[04:16] Managed Agents 与是否还需要理解 Harness

[事实] 主持人提到 Claude 推出了 Managed Agents，也就是把自家的 Agent Harness 能力开放给开发者使用。

[事实] 嘉宾认为，未来可能会出现像 Web 框架一样开箱即用的 Harness，但在当前技术周期中，开发者和创业者仍需要理解其内部变化。

[事实] 他认为不了解 Harness 的产品，会缺乏迭代空间和“灵魂”。

[事实] 嘉宾也认为产品经理需要理解技术周期的变化，因为当前 AI 产品是在吃技术进步的红利。

[06:59] Agent Harness 的三层结构

[事实] 嘉宾把 Agent Harness 拆成三层：执行能力层、上下文/环境层、治理编排层。

[事实] 执行能力层包括 CLI、代码注册工具、MCP 扩展工具等，为模型提供 action 能力。

[事实] 上下文/环境层包括 system prompt、skills、memory、上下文窗口管理，以及任务跨窗口交接。

[事实] 治理编排层处理多 Agent 的组织协作、权限治理、信息提供与隔离等问题。

[08:43] 用复杂项目解释三层如何协作

[事实] 嘉宾用一个大量 Agent 协同完成复杂项目的例子，说明单靠 action 工具无法完成长程任务。

[事实] 执行层需要提供文件增删读写、搜索等工具，让模型能够写代码和修改项目。

[事实] 上下文层需要让 Agent 知道当前路径、依赖、文件结构、Git 信息、已完成内容和下一步任务。

[事实] 编排治理层需要处理写代码 Agent、测试 Agent 的关系，并控制不同角色的权限，避免测试 Agent 为了通过测试而直接篡改代码。

[11:19] 现有 Infra 与 EKB/K 系列工具链

[事实] 嘉宾认为三层 Harness 目前都还没有被封装得非常好，因为 Agent 范式变化很快。

[事实] 他的公司在做一套 Agent 开发工具链，包括 K Computer、K Runtime、K Watch，以及数据导出和强化学习相关工具。

[事实] K Computer 被描述为在内存数据结构中实现的一台虚拟 Unix 计算机，为主动式 Agent 提供工作环境。

[事实] K Watch 用于观测 Agent 任务完成情况、卡点、工具设计、skill 设计和模型效果。

[14:01] 与云厂商 Agent Infra 的差异

[事实] 主持人提到 AWS Agent Core、阿里云 Agent Bay 等云厂商也在做 Agent Harness Infra。

[事实] 嘉宾强调他们的工具链并不只面向云端，而是希望所有能跑 JS 的场景都能使用，包括浏览器网页和微信小程序。

[事实] 他提出 K Computer 只有约 1KB，目标是在各种环境中提供统一、轻量的 Unix 式 Agent 工作环境。

[事实] 技术实现上，他们用数据结构重写 Unix 文件系统等抽象，并在支持 WebAssembly 的场景中切换到 Rust/WASM 实现，否则 fallback 到 JS。

[16:11] 工具层的关键工具与坑

[事实] 嘉宾认为最主要的工具包括文件系统工具、浏览器操作能力，以及 Python/Node 这类语言解释器。

[事实] 他认为这些工具组合可以覆盖大部分 Agent 任务。

[事实] 工具设计的坑主要在权限和角色绑定：探索代码库的 Agent 应该只拥有无副作用的读能力，而不应拥有写、删、改等能力。

[事实] 对浏览器或网络工具，也需要限制访问网域和可操作范围。

[17:38] Memory 的几类方案

[事实] 嘉宾把 memory 方案粗略分为规则式、半规则式和完全模型驱动式。

[事实] 规则式方案包括知识图谱、向量搜索、结构化节点表示和检索扩展。

[事实] 他更偏好半规则式方案，例如用 Unix files 和 Markdown 存储信息，再由 Agent 按规则维护、更新和查询。

[事实] 他提到 Claude Code、Manus 以及 MemU 都接近这种 Unix files 加 Agent 驱动维护的思路。

[20:14] Memory、Skill 与自迭代边界

[事实] 主持人提到大家开始混淆 memory 和 skill 的边界。

[事实] 嘉宾认为 Claude Code 早期的 insights 特性会分析近期对话，生成任务报告，并可指导 skill 生成。

[事实] 他认为 memory、skill、经验、SOP 之间存在很大交集，很多内容很难严格归类。

[推测] 这一段的重点不是定义名词，而是 Agent 如何通过历史经验持续学习和自我迭代。

[22:04] Harness 的共识与非共识

[事实] 嘉宾认为“Bash is all you need”或“CLI is all you need”正在成为一种共识，很多人开始优先给 Agent 提供 CLI。

[事实] 他指出，很多主流 Agent 框架仍然基于 prompt node、状态图、路由和条件规则，不是为这一理念原生构建的。

[事实] 他认为 K 系列工具链试图面向新的共识范式，提供 Agent 开发工具链。

[推测] 这段把 CLI/Unix 哲学放在 Agent Harness 的中心位置，弱化了 MCP 和传统流程编排框架的重要性。

[23:17] 从 Claude Code 泄漏源码学到什么

[事实] 嘉宾认为 Claude Code 的上下文压缩策略比外界想象得复杂，包括何时删除工具输出、压缩时保留或恢复哪些信息。

[事实] 他认为 Claude Code 的 memory 设计也很精妙，并且与 skills 机制遵循同一套哲学。

[事实] 他总结 Claude Code 的关键思想是：模型才是 Agent，要给模型合适工具和足够自由，而不是由程序员每一步替模型决策。

[事实] 他用“更多 context、更少 control、更多 action 能力”概括这种做法。

[25:00] 沙箱、K Computer 与取舍

[事实] 主持人提到 Manus 使用过云端沙箱 E2B，并询问沙箱领域的变化。

[事实] 嘉宾认为沙箱领域最近有很多聚合式方案，但大的进展还不多。

[事实] 他认为他们的 1KB Unix Computer 更极致轻量，本质上不是传统 sandbox，而是数据结构层面的虚拟计算机。

[事实] 这种方案无法真实运行 GCC 编译器或浏览器，但提供最小化 Unix 文件系统、Bash 命令能力、局域网通信、共享磁盘等能力。

[27:00] Claude Code 的“做梦”式记忆机制

[事实] 嘉宾说 Claude Code 有两套记忆更新机制：一套在每轮 Agent 工作结束后的 stop hook 上触发，另一套是 AutoDream。

[事实] stop hook 会 fork 一个 Agent，复用上下文和 KV cache，判断哪些信息需要保存到 Markdown 记忆文件中。

[事实] 这些 Markdown 文件类似 skill，包含 YAML 和 description，运行时先读文件名和描述，再判断是否加载全文。

[事实] AutoDream 大约每天触发，在满足会话数量条件后回顾最近会话，纠正、更新、合并和整理记忆。

[29:11] 上下文压缩与交接工程

[事实] 嘉宾认为 Claude Code 在上下文压缩和跨 Agent 交接上有大量工程兜底。

[事实] 当上下文窗口接近满载时，一种策略是踢掉不必要的工具输出或垃圾信息，腾出空间继续工作。

[事实] 另一种策略是在达到阈值时留下余量，生成进展文档，让下一个 Agent 读取后接着完成任务。

[事实] 上下文交接的关键问题是：哪些信息该交接，哪些不该交接，下一个 Agent 初始化时应加载什么。

[30:30] Harness 是 Agent 模型之上的工程实践

[事实] 嘉宾把 Harness 类比为新底层运行层之上的工程实践，类似 CPU、汇编、C、C++、Python/Node 等抽象逐层演进。

[事实] 他认为现在新的底层运行层是模型，而开发者很难直接修改模型参数，所以要围绕模型智能性做上层工程实践。

[事实] 他认为许多 Agent 最佳实践，如果从模型运行逻辑出发，会显得自然且符合直觉。

[推测] 这解释了为什么“less control more context”等实践看似反传统工程直觉，却适合当前 Agent 模型。

[32:35] 好 Harness 与坏 Harness 的标准

[事实] 嘉宾认为坏的上下文管理会随意裁剪历史轮次、修改系统提示词，导致提示词相关机制失效。

[事实] 他认为“最好的管理就是不要做管理”，因为过度管理可能破坏模型原本的运行逻辑。

[事实] 好的 Harness 应该与模型运行逻辑自洽，并且与模型未来能力进步方向正交。

[事实] 如果 Harness 随模型变强反而限制模型，就不是好的 Harness。

[34:23] Token 效率、模型阶段与未来差异

[事实] 嘉宾认为当前 Agent 模型还处于早期，很多东西没有收敛，不必过早过度讨论 token efficiency。

[事实] 他认为使用者应围绕 SOTA 和次 SOTA 模型构建产品和工具。

[事实] 在他的判断中，Anthropic 是 SOTA，Kimi、MiniMax 等最新一代模型属于紧贴 SOTA 的梯队。

[推测] 他更关注任务成功和范式适配，而不是在早期阶段过分优化单次调用成本。

[35:39] 模型、上下文、工具的重要性排序

[事实] 嘉宾把模型排在第一位，因为他认为“模型才是 Agent”。

[事实] 他把上下文排在第二位，包括工作目录、操作系统、工具形式、skills、memory 和跨 Agent 交接。

[事实] 他把工具排在第三位，并认为强工具能显著扩展 Agent 能完成的任务。

[事实] 他举 GitHub MCP 与 GitHub CLI 的例子，认为 CLI 的成功率更高，因为 Linux/命令行语料在预训练中更充分，而 MCP 是较新的协议和抽象。

[37:45] CLI 相比 MCP 的优势

[事实] 嘉宾认为飞书 CLI 相比此前给 Agent 使用的插件，在组合性、灵活度和任务完成率上更高。

[事实] 他观察到越来越多系统开始开发自己的 CLI 给 Agent 使用，而不是只提供 MCP。

[事实] 他认为 Unix 体系已经存在很久，训练语料更多、更充分，因此今天可能不该再造更多协议和轮子。

[推测] 这强化了他对 Unix、Shell 和 CLI 作为 Agent 原生接口的偏好。

[38:40] Agent Harness 催生的创业方向

[事实] 主持人询问除了 K 系列之外，嘉宾还看好哪些 Agent Harness 相关方向或团队。

[事实] 嘉宾提到混合组网需求：Agent 可能运行在云服务器、Mac、Mac mini、路由器、NAS、手机等不同设备上，而这些设备未必都有公网 IP。

[事实] 他认为 Tailscale 类工具展示了统一组局域网的价值，但还不够 Agent native，未来可能需要新的混合组网形态。

[事实] 他还提到 Agent payment，因为 Agent 之间可能产生高频、碎片化、小额支付。

[40:20] 个性化模型训练与推理

[事实] 嘉宾认为未来不一定每个人都只调用相同的基座模型 API，个性化训练会变得重要。

[事实] 他看好类似 T-Sync 的方向，即通过集中 GPU 和高速互联降低个性化训练成本。

[事实] 他设想 API 请求可以携带用户 LoRA 信息，在基座模型上瞬时挂载个性化参数进行推理。

[事实] 他认为这与他们的工具链互补，因为 Harness 运行会产生大量轨迹数据，可用于分析、迭代和训练。

[42:03] Agent Infra 赛道与创业初心

[事实] 嘉宾认为 Agent Harness 赛道会比较激烈，但未来未必需要很多水平差异化方案。

[事实] 他判断好的 Harness 要同时与模型运行方式和模型进步方向自洽，因此结构设计上不会出现太多派系。

[事实] 他们更偏 Unix 和 Shell 路线，试图提供虚拟化、极轻量的数据结构层 Computer，而不是传统 Docker/Sandbox 路线。

[事实] 嘉宾说公司的 slogan 是“加速世界升级”，目标是服务未来大量运行在地球上的 Agents。

[44:58] Agent 未来、群体协作与零人公司

[事实] 嘉宾预测，当前 Agent 模型阶段可能还会持续几年，下一步会从单体 Agent 走向 Agent 群体协作。

[事实] 他认为未来不只是人管理 100 个 Agent，而是 Agent 自己管理和协调更多 Agent。

[事实] 他进一步设想 Agent 能做发明、驱动企业运行，并形成“零人公司”。

[事实] 主持人提到 YouYouAgent：创作者把 Agent 做出来后不再写代码或投钱，让它自己进化、筹钱买 token，并以超越 Claude Code 为目标。

[推测] “投资标的从公司变成 Agent”是节目中最激进的未来判断，也代表了嘉宾对 Agent 经济主体化的想象。

播客点评/总结

[推测] 本期的价值在于把 Agent Harness 从抽象热词拆成了具体工程问题：工具怎么给、上下文怎么保、记忆怎么更新、权限怎么管、多 Agent 怎么交接和编排。对于想理解 Claude Code 为什么强的人，这期提供了清晰的技术框架。

[推测] 亮点是嘉宾立场鲜明，反复强调“模型即 Agent”“更多上下文、更少控制”“CLI/Unix 优先”。这些观点不一定是行业最终答案，但能帮助听众理解当前 Agent 工程实践中一条重要路线。

[推测] 局限是讨论高度集中在嘉宾自己的技术哲学和创业方向上，对其他 Harness 路线的优点展开较少；部分未来判断，如零人公司、Agent payment、个性化 LoRA 推理，还处在预测和设想层面。

[推测] 这期更适合 AI 产品经理、Agent 开发者、AI infra 创业者，以及已经用过 Claude Code、Manus、MCP、CLI 工具并希望理解其底层设计差异的听众。