Theo：智能体 Harness、界面与不断变化的抽象层次

我从一条帖子说起：关于智能体 harness 的争论可能类似于制表符与空格之争。作者就是我本人。我开发 T3 Code，但想解释 harness 的作用，以及为什么我认为多数用户会越来越不在意自己用的是哪一个。

开发者一直关注不同层次的细节。格式可能关系到无障碍或一致性，而产品、构建产品的人和架构，对结果可能更加重要。

随着抽象能力提升，关注的边界也会移动。程序员过去必须密切关注处理器指令；C 等语言让许多开发者可以在更高层工作，但底层指令并没有消失。

编辑器、格式化工具和 linter 减少了争论许多排版选择的必要。随后，AI 补全让人们更容易说出熟悉的算法名称并生成实现，再次改变了我投入精力的位置。

工程师习惯于关注外行认为不重要的细节。这种习惯可能有用，但我认为它也可能让我们在某个层次值得投入精力的实际价值下降后，仍继续捍卫它。

我指出，关注点正在从框架发布转移，并说模型可以帮助把代码改写成另一种语言。我也认为它们能帮助发现架构问题，但我明确不认为模型的架构工作已经完美。

我回忆自己发现后端故障，并用 Claude 设置追踪、为 Cloudflare 生成报告的经历。这是我对特定事件的叙述，不是对模型与工程组织进行的受控比较。

为解释 harness，我从一个简化模型开始：大语言模型接收文本并生成文本。文本本身不会编辑文件或运行命令；必须有东西解释它，并将它连接到行动。

我的厨房比喻是一位身处空房间的熟练厨师。即使有菜单并能描述菜肴，没有厨具和食材也无法烹饪。程序员面对没有键盘的显示器，也遇到了类似的接口问题。

harness 为模型提供请求操作和接收上下文的方式。它可以解释受支持的工具调用格式，安排读取文件、编辑或执行命令，再把结果返回给模型。

我将面向人的界面与其下方的 harness 区分开。按照我的术语，Claude Code 这样的产品可以同时包含界面和智能体 harness；SDK 则可以把底层智能体能力暴露给其他应用。

我认为 T3 Code 主要是界面，而不是独立的 harness，尽管它会影响所连接 harness 的使用方式。当用户切换提供方并期待所有设置随之迁移时，这一区别就很重要。

在这套解释中，我把智能体称为模型与 harness 的组合；harness 提供工具、上下文和指令。不同 harness 暴露的内置能力也不同，例如 shell、文件编辑或子智能体。

插件可以增加查找定义等能力，计算机操作集成可以暴露点击或输入等操作。添加一个工具，并不意味着这个工具本身就是整个 harness。

我单独画出一层，用来访问外部系统和数据。食谱的比喻旨在将这类连接与直接内置于特定 harness 的工具区分开，尽管两者最终都可以给智能体提供有用的操作。

例如，MCP 集成可以让智能体访问数据库或分析服务。自定义工具可能在某个 harness 中实现，而约定的协议可以把它连接到其他地方承载的功能。

我说 T3 Code 使用 MCP 连接，让自身代码在不替换各个 harness 内置工具的情况下转发操作。这个设计旨在让已连接的智能体搜索历史，或通过另一个连接的系统请求工作。

工程师关注的层次可能反映他们进入这个领域的时间。我开始制作视频时，框架之争很突出；后来我对基础设施和 AI 智能体产生兴趣。这是我的个人模式，不是普遍规律。

我讲述自己从后端工作转向前端 TypeScript 和 Web 开发内容的经历。最近与 Claude Code 创建者的一次对话让我意外：他知道我现在的 AI 工作，却不知道我此前的 Web 开发背景。

即使新抽象让熟悉的专长显得不再那么核心，我仍喜欢学习它。我用滑板解释，为什么用不熟悉的站姿重新开始，不只是令人沮丧，也可能带来乐趣。

想象跨越一个栏架，然后在脑中交换双腿。我说，在滑板中，用相反站姿完成一个动作，对有经验的滑手来说是明显的挑战，尽管外行可能只看到相同的动作。

我把这比作有经验的程序员使用不熟悉的语言：程序可能能运行，但第一门语言的习惯仍可能显而易见。专业专长可以很有价值，但切换层次需要重新学习。

滑板教会我享受用不同方式做事时的不适过程。我担心，对某个工具投入很深之后，人们可能更难注意到另一种方法何时变得更有用。

我讲述自己采用 TypeScript 的经历：我没有多年旧 JavaScript 习惯带来的包袱。我对继续使用那些习惯的开发者的批评，反映的是自己的经历与判断，并不能证明某个工具会决定一个人的职业生涯。

我对长期坚持某类编辑器提出了挑衅性的预测，并认为人们也可能对单一模型系列或 harness 产生类似忠诚。我想表达的是，最合适的选择可能发生变化。

我曾假设深度投入某种 TypeScript 抽象的团队会抗拒切换层次，但其创建者表示自己不再在意使用哪个 harness，这挑战了我的假设。

T3 Code 用户有时从一个已连接的 harness 切换到另一个，并期待第一个中配置的技能自动出现在第二个中。我说，看似模型选择器的控件同时也在选择具有自身配置的 harness。

我把 T3 Code 比作拥有多个厨房的美食广场。选择另一个厨房，不会自动把所有食材或食谱搬过去；界面必须处理这些差异。

我的目标是让切换体验更像更换模型或 API 选项。我还预计模型会与其偏好的 harness 联系得更加紧密，因此界面如何呈现这些组合仍会重要。

我以前花了大量精力比较使用不同编程模型的方法。现在，对于自己的工作流程，我认为其中许多差异很小，同时也承认其他用户和任务可能有不同需求。

让 harness 差异变得不明显，对界面开发者来说不一定更容易：T3 Code 仍须处理不同的子智能体与工具行为。我的观点是，用户不应总是自己管理这些复杂性。

我把 T3 Code 称为智能体开发环境：它向人呈现工作，并连接 harness、环境和远程机器。这个类比是 IDE，但活动中心是管理智能体工作，而不是直接编辑每一行代码。

我想要的是一个开放、可定制的界面来控制自己的 AI 工作，而不是再造一个 harness。我预计，随着人们在更多地方与智能体互动，这些界面本身也会变得不那么显眼；但我现在仍在意把它做好用。