首页 > 教程攻略 > ai资讯 >DeepSeek Harness被谷歌盯上：Agent下一战场，开始从模型转向系统

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

来源：互联网时间：2026-08-19 13:55:23

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()从事件流的模型可见投影中派生而来的。