AI Engineer 会议热议：Harness 工程与评估框架

AI Engineer 世界博览会报道

本周，我正在旧金山参加 AI Engineer 大会。你能想到的各大知名品牌几乎都赞助了这场活动，登台分享的是一众在互联网上颇具名气的项目维护者，庞大的议程安排也几乎照顾到了所有人的兴趣。在如此嘈杂的信息中，人很容易迷失方向。因此，我把时间用来判断：哪些主题是真正存在的趋势。

大会设有数十条专题轨道，聚集了数千名构建者，整个生态看上去极其分裂。但如果观察工程师真正投入生产环境的东西，这种混乱就会收敛成一种清晰的模式。这个行业正在越过简单的聊天界面阶段，开始把大语言模型视为更庞大、高度结构化的软件架构中的中央处理器——本质上就是一个 LLM Operating System。

我整理了现场看到的一切，深入了解了各项技术专题，最终归纳出以下六个主题。这并不代表我认可它们，我也没有把炒作与现实区分开来。你可以把这些简短总结当作进一步探索的起点；如果其中某个想法激起了你的好奇心，不妨继续深入研究。

1. 转向仓库级“软件工厂”

过去几年，开发领域的 AI 基本上就是 tab-complete。你写下一行代码，助手建议接下来的几个 token，然后继续往下写。

这种以单个文件为中心的方式正在迅速过时。关注点已经转向仓库级、多 Agent 系统，也就是人们所说的 Software Factories。

开发者不再只是与 AI 助手并肩逐行编写代码，而是开始管理一整支能够跨越整个代码库工作的 Agent 队伍。例如，Uber 分享了其内部代码审查引擎 uReview 的详细信息。它使用 Agent 自主审查 pull request、启动局部测试套件、发现边界情况，并在人工查看之前直接把修复提交回对应分支。

为了让这套流程更加可靠，工程师把编译器和 linter 直接接入 Agent 的反馈循环。如果生成的代码无法通过编译，原始错误输出就会被直接送回 system prompt。模型读取自己的错误、修复 bug，然后自主重新运行检查。

2. 通过“Harness Engineering”加固系统

目前，大会现场形成了一个普遍共识：“每个人都在构建 Agent harness，只是没人这么称呼它。”

LLM 天生具有概率性和非确定性。然而，软件基础设施要求输入和输出必须可预测。为了解决这一矛盾，团队正在把一项核心系统工程实践正式化：Harness Engineering。

所谓“harness”，就是构建在模型外部的一层严格软件封装，用来强制执行约束、管理状态，并防止出现无限执行循环。

开发者不再允许 Agent 在无人监控的情况下持续运行，而是使用 Temporal 或 Inngest 等工具链实现 durable execution。如果一个 Agent 正在执行复杂、持续数小时的工作流，却遇到了网络超时，harness 会保留它的记忆和状态。整个流程可以从失败的位置准确恢复，无须重复发起成本高昂的 API 调用。再配合 Pydantic 或 Instructor 等库，强制模型严格遵循 JSON schema，harness 就能让不可预测的模型表现得像稳定的基础设施。

3. Computer Use 与自定义 API

数十年来，系统集成意味着编写自定义 API connector 或抓取 endpoint。今年的一大主题是 Computer Use——构建能够像人类操作员一样使用软件的 Agent：观察屏幕、移动鼠标并输入命令。

得益于更优秀的视觉语言模型（VLM），这些系统不再需要结构化的后端 API。它们会持续截取图形用户界面（GUI）的屏幕截图，解析视觉布局以定位字段和按钮，然后在精确的像素坐标上执行操作。

这也迫使本地开发环境发生转变。工程师正在构建隔离的沙箱终端和开源桌面助手，例如 OpenClaw，为后台 Agent 提供各自独立的虚拟环境。这样一来，Agent 就能在隔离环境中启动本地服务器和调试文件，而不会接管工程师正在使用的屏幕和键盘。

4. Context Engineering 与“Tokenmaxxing”

context window 已经扩展到数百万 token，但把整个代码库一股脑塞进 prompt，是一种成本高、延迟大的反模式。

如今，time-to-first-token 和 API 成本才是真正的瓶颈。因此，开发者开始高度重视 Context Engineering——把 context window 当作经过高度优化的动态内存缓存，而不是静态的文本堆积区。

这种优化策略通常采用三层方法：

Prefix Caching：vLLM 等推理引擎会缓存静态 system instruction 或文档头部的 Key-Value（KV）状态。后续请求可以复用这些缓存，从而显著降低延迟和成本。

Prefix Caching：vLLM 等推理引擎会缓存静态 system instruction 或文档头部的 Key-Value（KV）状态。后续请求可以复用这些缓存，从而显著降低延迟和成本。

Context Compression：引入 middleware layer 运行语义压缩算法，在把数据发送给服务提供商之前，裁剪无关 token，并对杂乱的聊天记录进行总结。

Context Compression：引入 middleware layer 运行语义压缩算法，在把数据发送给服务提供商之前，裁剪无关 token，并对杂乱的聊天记录进行总结。

Graph RAG 与 Hybrid Retrieval：系统不再不加区分地拉取原始文本块，而是使用结构化知识图谱，只把高信号数据送入当前活跃的 context window。请前往 link.dev.to/aie39 阅读全文。

Graph RAG 与 Hybrid Retrieval：系统不再不加区分地拉取原始文本块，而是使用结构化知识图谱，只把高信号数据送入当前活跃的 context window。请前往 link.dev.to/aie39 阅读全文。

5. 告别“凭感觉”的评估

如果说有一种明确的运营方式转变，那就是：凭感觉做工程的时代已经结束了。检查几个输出结果，认为它们看起来还算合理，然后直接发布到生产环境，这种做法已经无法接受。

Evals 社区目前关注的核心，是自动化的多步骤模拟 benchmark。如今，评估一个 Agent 需要启动隔离的虚拟环境——一个带有 mock 数据库和网络访问能力的临时沙箱——然后让 Agent 尝试完成一项复杂任务。评估框架不会给回复的表达风格打分，而是检查任务是否成功完成、记录完成任务用了多少个步骤，并验证过程中是否违反了任何安全协议。

工程师也在摆脱“Persona Trap”——也就是向模型提供“You are a senior staff engineer”之类的 prompt。大会上分享的研究表明，这种方式评估的是风格上的感觉，而不是严谨的技术能力，并且经常引入难以察觉、会降低性能的偏差。如今的标准是严格且以任务为导向的测试。

6. 使用安全的 Micro-Sandbox 保障运行时安全

赋予 Agent 编写代码、修改文件和运行终端命令的权限，会带来严重的安全风险。

平台工程师正在从底层执行层着手解决这个问题。行业标准已经逐渐统一到 Micro-Sandbox。Agent 生成的代码会在轻量、短暂存在的 micro-VM 中执行，例如 E2B 或 Docker 提供的环境。这些环境可以在几毫秒内启动，处理特定计算任务，然后立即销毁，以防止 container escape 或对持久文件系统的篡改。

业界也在大力推进 credential masking。当 Agent 需要访问企业数据库或第三方工具时，工程师会使用 AAuth protocol 等新的 delegation layer。这种机制会授予 Agent 仅限当前任务的工具调用权限，同时阻止 Agent 看到或接触原始 API key，从而消除由 prompt injection 导致的凭证泄漏。

浏览这些主题时，人很容易产生一阵 FOMO，并认为如果自己还没有运行一整支 micro-sandbox 队伍或自主软件工厂，就已经落后了。

不要被炒作裹挟。你不需要在下周一之前彻底改造整个技术栈。

事实上，Moscone 会场所有喧嚣背后真正传递出的结论相当令人安心：AI 正在变成普通的软件基础设施。未来几年，能够构建出实用产品的开发者，不会是那些追逐每一个闪亮新模型或复杂 multi-agent framework 的人，而是那些坚持运用基础甚至有些乏味的工程原则的人——让输入变得可预测、严格测试代码，并确保运行环境安全。

如果你正在寻找一个起点，不要把事情搞得过于复杂。从日常工作中挑选一个单一、重复的工作流，为它封装一层整洁、具备防御性的代码 harness，再构建一个简单直接的评估脚本来检查它的工作成果，然后看看会发生什么。灵感固然重要，但真正能把产品交付出去的，始终是务实。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。