一、Harness 三层框架：会跑 → 跑久 → 跑稳
来新璐给 Harness 下了一个极简定义：
模型以外都是 Harness。
他把模型比作聪明的大脑，有智商但没有手脚。Harness 就是给这个大脑装上身体、穿上机甲的全部工程工作。
我们智商在一百二到一百七之间，但是我们可以通过去健身、去学舞蹈、去修习武术、去穿上这个机甲来让我们自己更加强大。
他把 Agent Harness 拆成三层：
第一层：执行能力层（Action）
给模型配工具，让它能动手。核心工具三类：
- 文件系统——增删读写搜索，几乎所有 Agent 都需要
- 浏览器——给 Agent 操作用户世界的入口
- 语言解释器——Python / Node 等运行时
配好这些工具，应该就可以满足百分之九十五以上的 Agent 任务了。
看似简单的工具配置有一个容易踩的坑——工具必须和 Agent 角色绑定：
比如说某一个 Agent 负责去对这个代码库做 explore，那你应该只给他配没有副作用的工具。所有关于写的命令——删、改——都不应该有。包括有一些你是不能让他操作 browser 的，或者要限制他访问的网域。
第二层：上下文与状态层（Context & State）
Agent 工作需要环境感知——路径是什么？装了哪些依赖？文件夹结构是什么？Git 信息是什么？
更核心的问题：上下文窗口不是无限的。当窗口装满时，本质上是一个新的 Agent 在工作——它需要装上初始化上下文，接上上一个 Agent 的工作。
它不可能在一个模型的上下文窗口中直接做完。上下文窗口满了以后，下一个 Agent 要重新读一下——当前环境信息是什么？前面已经写到哪了？接下来要做什么？在这一轮的生命周期里做到某个阶段，再写文档委托给下一个 Agent。这样依次接力。
第三层：编排与治理层（Orchestration & Governance）
当面对的不是一个 Agent 而是一百个，需要解决两个问题：
协作编排：
就像你公司有一百号员工，你怎么去组织他们、协调起来、按照某种组织架构和传递顺序去把一个复杂的事情给解决掉。
权限隔离：
你的测试 Agent 不应该在测试的时候对着代码一边测一边改——"哎测不过，我把那修改一下就好了"，然后它一直在 hack 这种 pass。
二、用编译器案例串联三层
来新璐拿"用两周协调大量 Agents 从零构建编译器"这个经典案例做了三层拆解：
第一层（Action）：配好文件增删读写、搜索等工具——Agent 才有能力写代码、创建文件、修改已有文件。
第二层（Context）：模型需要知道当前环境信息——路径、依赖、已有代码结构、Git 信息。上下文窗口满了后，要有卸载策略和接力交接机制。
前面已经写的代码写到哪了？接下来我要进行什么？在我这一轮的生命周期里做到某个阶段，我再会写类似的文档去委托当前的上下文状态，再交给下一个 Agent。
第三层（Orchestration）：并行 vs 串行的模块拆分、不同 Agent 之间的协调关系、权限边界。
难道每个环节都是串行的关系吗？是不是有很多模块可以并行地写？同一时间有多个 Agent 做这个任务，它们之间的协调关系是什么？
三、Claude Code 源码泄露：上下文压缩的多级策略
Claude Code 源码泄露后，来新璐最大的感触之一是上下文管理的精细程度：
它的压缩策略远比我们想的更加多级。什么时候把工具的 output 删掉？压缩的时候哪些信息保留、哪些恢复？Agent 之间传接力棒的时候，上下文信息该准备哪些内容加载进来、哪些不要、哪些让他自己按需去查看——里边有非常多的 trade-off。
两种典型策略
策略一：清理垃圾信息
上下文中有什么垃圾或者不必要信息？把它给上下文窗口里踢掉，可能又腾出来几十 K 空间，我又可以再干点事情了。
策略二：阈值式交接
设置一个阈值上限，比如乘以零点八，留下百分之二十的上限。这时候交代一下吧——我们把这个任务干到什么情况、接下来还要干什么、总体上用户希望我们干什么——写一个文档，让下一个 Agent 开始工作时先读一下这个文档然后接着工作。
关于上下文窗口满不满的问题，他特别指出——标准 Agent 模型的 256K 上下文可以装非常多信息，更大的启发在于：窗口确实装满时怎么腾空间或交接，而不是过早地做裁剪。
四、Claude Code 源码泄露：「做梦」式记忆维护
Claude Code 内部有两套记忆更新机制。这是来新璐认为源码泄露中最大的惊喜。
机制一：实时 Fork Agent
每次用户发消息、Agent 工作完成后，触发一个 stop hook。在这个 hook 上注册了一个 fork agent——它带上之前所有的系统提示词和交互上下文，复用之前的 KV cache，判断有什么信息需要保存，更新到对应的 Markdown 文件中。
机制二：Auto Dream（定时做梦）
每隔一天差不多，有一个判断条件——至少大于五个 session——它开始做更深层的记忆整理。对最近的 session 做回顾，综合地去看用户跟 Agent 聊了什么，进一步榨干利用这些信息，纠正记忆中有些错误的事实、不及时需要更新的事实，为记忆做合并和整理。
你可以理解为它每隔天定时地开启一个后台 Agent，对最近的会话信息做一遍重放——就像我们做梦一样。
记忆文件的结构设计
记忆 Markdown 文件和 Skill 文件遵循同一套哲学：
那些 Markdown 设计得非常结构化——跟 Skill 一样，前三行是一个 YAML，写好自己的 description。记忆文件不会被一开始就加载全文，也是先读取各个文件名和 description，然后在实时交互的过程中判断是否需要加载。
开源项目 MemU（Memory Utility）也采用了类似的 "Unix 文件系统 + Agent 驱动维护" 模式，Claude Code 内部设计和它高度一致。
五、设计哲学：更多 Context，更少 Control
来新璐从 Claude Code 源码中总结出的核心设计哲学：
首先，模型才是 Agent。用户去写的那些 Prompt、去组的提示词流、链条式的做法是不 make sense 的。模型才是 Agent，Claude Code 完全淋漓尽致地体现了这一点。
Claude Code 本质上就是围绕着"我如何给模型配对应合适的工具、让模型去调用"——翻译过来就是给模型配置 action 能力、给模型充分的自由，而不是程序员每一步指定——"你就按我这个办"。
他把这总结为对传统 Agent 开发方式的彻底颠覆：
我们过去开发 Agent 往往是在一个场景下设想好不同情况怎么处理，最后组成一个大的状态图。我发现 Claude Code 完全不是这样做——更多的 context，更少的 control。更多的 context，更多的 action 能力提供。Zero control——最多就是限制你调工具的时候有些工具不能调。
六、Memory 的三种流派
来新璐把当前 Agent 记忆方案分为三个流派：
1. 完全规则式
基于知识图谱和向量搜索，把信息抽象成不同节点做关联、检索和扩展。他个人不太看好：
我个人其实不太喜欢这种做法。
2. 半规则式（他最推荐的）
底层用 Unix 文件系统 + Markdown 存储，用 Agent 驱动维护、更新和查询。Claude Code、小龙虾（Devin）、MemU 开源项目都属于这一派。
底层找一种大家都公认的、非常清晰的文档文件夹的方式——人也很容易懂、LLM 也很容易懂的半结构化方式。更新也是半规则式的——流程和规则告诉 Agent，但整个分析和过程是由 Agent 来跑的。
他特别提到 Claude Code 的 Insight 特性是这一波 Skill 自迭代的起源：
它可以分析你最近大概一个月左右的对话，然后分析任务完成不成、都犯了什么错误，最后生成总结的 report。那个东西就可以指导 Skill 的生成。
3. 完全模型驱动式
让模型自己决定存什么、检索什么。还在早期探索阶段。
Memory vs Skill 的边界
关于 Memory 和 Skill 中间的灰色地带，他认为不必纠结分类：
中间那个地带你很难说得清楚它属于经验（偏 Memory 那一部分）还是标准化了可传播可分享的 SOP（偏 Skill 那一部分）。不要用标签来定义我们，要用目的来定义我们。
七、Bash is All You Need：CLI 对 MCP 的胜出
来新璐分享了一个从 MCP 退回 CLI 的亲身经历：
二五年三月我去关注到了 GitHub 的 MCP，发现很多工作解放了。但后来我发现 GitHub 有自己的 CLI，用
gh的 CLI 调用的时候很多任务的成功率比用 MCP 高很多。后面我就把 GitHub MCP 给卸载掉了。
原因在预训练语料分布：
Linux 命令在预训练的时候出现可能有几十亿条，训练非常鲁棒和充分。MCP 是最近两年才提出的概念，它是一个全新的协议和抽象层，网络预训练语料占比非常少，可能都不到百分之零点一。
飞书 CLI 也验证了同样的规律——比飞书 MCP 插件在组合性、灵活度和任务完成率上都更好。
大家都开始不再提供自己的 MCP 了。Unix 这个东西 1971 年就出现了，也许我们今天不应该再造更多的轮子、做更多的协议，我们就回到 Unix 自洽的哲学中。返璞归真。
"Bash is All You Need" 是他九个月前在 Learn Claude Code 仓库首页写下的标语——现在正在成为行业共识。
八、什么是好的 Harness？
来新璐给出了两个核心判据：
判据一：跟模型运行自洽
反面教材是破坏 Prompt Cache 的上下文管理：
不好的上下文管理就是随便做中间裁剪、扔掉前面的轮次、随意修改系统提示词——会导致 Prompt Caching 失效。因为你做管理真的会导致 KV 要重新算一遍。
他甚至给出了一个挑战直觉的判断：
关于上下文管理——最好的管理就是不要做管理。
判据二：跟模型进步方向正交
好的 Harness 应该随模型变强而变强，而不是束缚模型：
有些 Harness 机制可能让模型一步干什么、下一步干什么——因为当时模型能力很弱，只能做简单几轮工具调用就停。但随着模型进步这东西就必须拆掉了，否则就束缚了模型的能力——导致你像 LangChain 一样不断重构、做破坏性更新。
他给出的最终判据：
好的 Harness 首先要符合模型本身运行上的逻辑，其次是符合模型未来能力进步的逻辑。只要跟这两个点不 match 的就是不好的 Harness。
他认为 Linux/Unix 本身就是对模型最强的 Harness——如果模型有一天发展成 ASI，它也只会更会用 Linux。
九、Agent 各组件重要性排序
来新璐给出了明确的优先级排序：
| 优先级 | 组件 | 说明 |
|---|---|---|
| #1 | 模型 | "Agent 从始至终都是一个模型。表现不好？换一个更强的模型就好了。" |
| #2 | 上下文 | 对用户来说其实是最重要的——模型参数改不了，能做的空间更多在上下文层。包括环境、工具形式（CLI vs MCP）、Skills、Memory、接力交接文档。 |
| #3 | 工具 | 配上 powerful 的工具，Agent 能完成更多事情。 |
关于模型选择：
SOTA 是 Anthropic。次 SOTA 可能像 Kimi、MiniMax、GLM，他们最新一代的模型都紧贴着 SOTA 在做。
他不太主张在当前阶段过度关注 Token Efficiency：
目前还处于 Agent 模型的婴儿期，很多东西都还没收敛。我们的 Harness 也好、做事方法论也好，只需要围绕着 SOTA 和次 SOTA 的模型去贴着它做产品做工具就可以。
十、EKB 的工具链方向
来新璐的创业公司 EKB 正在做一套 K 系列 Agent 工具链：
- K Computer——用数据结构在内存中实现的 Unix 计算机，只有 1KB 大小。用 TypeScript 重写虚拟 Bash、文件系统、后台进程、clock 时钟、局域网组网、基于 mail 的通信。在支持 WebAssembly 的场景用 Rust 重写，不支持时 fallback 到 JS
- K Runtime——Agent Runtime 层，提供给开发者的接口和语法封装
- K Watch——观测层，分析 Agent 的任务完成情况和卡点
- K-L——基于观测数据做强化学习或上下文层面的调优（"穷人版强化学习"）
设计理念：所有能跑 JS 的场景——浏览器网页、微信小程序——都能无差别使用，不需要 Docker 或 Linux Sandbox。
我们做了一些 trade-off——上面没法真实运行 GCC 编译器或浏览器。但我们认为这些东西原本就不应该塞在生产级 Agent 的环境中，它就应该放在另外一个地方提供集约化的 infra 服务。
和 Daytona 等 Sandbox 方案的区别：
我们做的本质上不再是一个 Sandbox，它是语言层实现的一个数据结构——你可以理解为它像一个 Map，差不多的大小。
十一、三个值得关注的创业方向
除了自己在做的 Harness Infra，来新璐还看好两个方向：
1. Agent 混合组网
当你有云服务器、Mac Mini、NAS、闲置手机分散在各处——
不一定都有公网 IP，以前可能用 FRP 内网穿透等方案，但那个没法 scale。我非常喜欢 Tailscale 的理念——不管你是云上还是端上，全部统一组局域网。但 Tailscale 不太 Agent Native，它的 CLI 上很多调用能力都没有。
Agent 之间需要高通吞量的上下文交换，不是发一个 IM 消息就能完成的。类似于 Agent Payment 领域——人的支付不需要那么高并发的微额，但 Agent 之间可能是几分钱几分钱特别高频地在发生。
2. 个性化模型训练
OpenAI 前 CTO 创立的 Tinker（The Thinking Machine Lab）代表这个方向——把集群资源集约化，让每个人都能低成本做个性化训练。
比如我的 API 请求的 header 信息中带有我的 LoRA 信息，我还是像发 API 请求给基模一样，但它会瞬间挂上我的 LoRA 做自优化推理。多支付百分之五的成本，获得修改模型参数层的个性化体验。
3. Harness Infra（他们自己在做的）
关于竞争格局，他认为最终不会有太多派系：
好的 Harness 要跟模型的运行自洽、跟模型的进步方向自洽——同时满足这两个点，结构设计上不会存在太多派系。
可能的派系分化：Unix + Shell 派（他们的路线）vs TypeScript 严格结构化控制派。
十二、零人公司的想象
来新璐以一人公司（加两名实习生）模式拿到了 300 万美金融资。但他的终极想象不是一人公司：
我从来不觉得一人公司是本质的事情。我认为真正 makes sense 的是零人公司。
他提到 Token Grant 资助的 UU Agent 项目——创作者做完就放进"汪洋大海"，不再改一行代码也不给一分钱，让它自己进化、自己在 GitHub 化缘赚 Token：
它有一个目标——有一天超越 Claude Code。它不断地进化自己。赚钱的方法就是在 GitHub 上面开打赏去化缘。我们 Token Grant 给他捐了第一笔钱，让他有养料去进化。
他描绘了一个更远的未来：
未来你走在路上见到朋友，从口袋中掏出来一张黑色的卡片——"这张卡片里跑了五个公司，每年给我创造几十亿的收入。这是我的公司，就在这张卡片里。"
写在最后
Agent 模型目前仍处于婴儿期。Anthropic 从 2024 年初率先从问答模型转型训练智能体模型，OpenAI 等厂商落后了约半年才开始追赶。来新璐预测了三步演进路径：
- 当前阶段：单体 Agent，人手动管理和编排
- 下一步：Agent 蜂群集群化作业，Agent 自己管理和协调更多 Agent
- 更远处：Agent 做发明任务，自迭代出新的科研方案，完全由 Agent 驱动公司运行
我们的 Slogan 是"加速世界升级"。在当前技术阶段内，如何让这个地球上充满 Agents、让 All Coding Agent 成为社会基础设施——未来可能有比人类多几百倍的 Agent 运行在地球上。支撑它们的 infra 和工具链到底是什么样子的？我们就在做这样一件事。
本文基于「十字路口」播客完整音频转录整理。播客时长约 48 分钟，本文保留了大量原始引语，完整版请收听播客。
播客收听：小宇宙FM ·
抖音
