DeepSeek Harness被谷歌盯上：Agent下一战场，开始从模型转向系统

DeepSeek Harness开源后引谷歌关注，Agent战场从模型转向系统设计，5大关键模式解析可追溯治理之道。
核心内容：
1. 日志作为事实源：Session事件流设计确保可追溯
2. 治理与安全保障：Agent卡住提醒、代码编排治理等机制
3. 长期任务与状态管理：模型查看完整性、Workspace留长期状态

导读 DeepSeek Harness开源后，不少人可能会觉得，这不过是DeepSeek自家的Coding Agent框架罢了。但当你把代码和文档拆开细细研究，就会发现它要解决的问题，可绝不仅仅是一个Agent Loop那么简单。DeepSeek将Model、Tools、Skills、Sessions、Sandboxes、Storage、Loops、Scheduling以及UI等全部纳入插件体系，并且用“Everything is a plugin”和“Every run is traceable”来概括这套架构。之后，Google Cloud高级AI产品经理Shubham Saboo对这套Harness进行了解析，从中提炼出5个值得Agent开发者关注的设计模式。需要注意的是，Shubham的公开身份是Google Cloud高级AI产品经理，并非“谷歌工程师”；而且这篇文章只是他个人的技术观察，并非Google官方评价。

主要内容包括以下几个部分：

1. 让日志成为事实源

2. Agent卡住时，先提醒它

3. 让模型知道自己没看全

4. 代码编排不能绕过治理

5. 长期状态留给Workspace

---

这5个模式分别落在Session、Guard、工具输出、Code Mode和长期任务编排，但共同指向一个问题：当Agent开始真正读文件、跑命令、调用工具并跨轮执行时，Harness怎样把可追溯、可纠偏、可治理和可延续变成系统能力。01

让日志成为事实源

乍一看，第一个设计似乎只是日志，可实际上，它对Agent能否真正被复现起着关键作用。许多Agent系统同时维护着两套状态：一套是模型实际接收到的Context，另一套是系统事后记录的Log。一旦任务变长，只要中间出现Context Compaction、Tool Result裁剪、System Prompt注入、Session Resume或者插件动态加入上下文等情况，这两套状态就可能逐渐出现偏差。最终，你或许能知道Agent调用了哪个工具，但却未必能确切回答：它做出这个决定时到底看到了什么。而DeepSeek Harness则将这层关系进行了反转：Session本身是一份append-only事件日志，官方dsh-session文档将其定义为Agent交互历史的source of truth，而LLM看到的Message History则是通过deriveMessages()从事件流的模型可见投影中派生而来的。

往期推荐

走进腾讯滨海大厦：探索AI搜索在Agent时代的范式跃迁！

同一个模型从7.8%到93.3%：Agent榜单，正在从“比模型”变成“比系统”

企业80%的知识困在文档里，AI却"读不准"——非结构化数据处理为什么是企业AI落地的第一张多米诺骨&牌？

业务团队需要的不只是查数入口，而是能做决策的智能体

175 亿美元估值 CEO：大模型越强，为什么企业反而更需要“自己的模型”？

AI生成代码涌入仓库，传统研发体系正在崩塌——微博李庆丰出品DACon「研发范式与组织进化」论坛

为什么实时 Agent 不能只有一个 Loop？Google AMIE 用三个 Agent 把“说、想、看”拆开了

DeepSeek V4 Pro 87.9 分背后：Agent 榜单正在变成 Harness 榜单

用自然语言建数仓：AI 重构数仓开发全流程

Gemini 3.7 Flash 三周接棒 3.6：Google 正把模型迭代拉进 Agent 节奏

点个在看你最好看

SPRING HAS ARRIVED

登录查看剩余 70% 内容