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

第一个设计看起来只是日志，实际上关系到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()从事件流的模型可见投影中派生。

这样一来，Log不再只是Agent运行后的“录像”，而成为状态基础设施。System Prompt、Reasoning、Tool Call和Tool Result、Sub-agent Scheduling、Context Injection等模型可见信息进入同一条Session Event Stream，Resume、Fork、Search和Replay也围绕这条事件流工作。Context不再是另一套需要同步的状态，而是Log的一种模型视图。Agent出错时，系统因此不仅能追踪“它做了什么”，也更接近还原“它为什么会这样判断”。

第二个设计解决的是Agent常见的“原地打转”。搜索没有结果就用相同参数再搜，命令失败后继续执行同一条命令，工具没有带来新信息却反复调用。最简单的Guardrail可以规定“重复三次就禁止”，但DeepSeek Harness没有这样做。它提供repeat-tool-reminder插件，官方把它定义为advisory loop-breaker：插件不会出现在模型的Tool List里，也不会直接veto或改写工具调用，只观察“同一个工具+相同规范化参数”的连续调用，并在默认3、5、8次阈值上向模型注入逐级增强的提醒。

重复并不天然等于错误：网络请求可能需要重试，异步任务可能需要轮询，外部环境也可能在两次调用之间变化。因此DeepSeek没有直接替模型做决定，而是补给它一层Meta Observation。普通Tool Result只能告诉模型“刚才发生了什么”，Repeat Reminder则告诉它“你已经用完全相同的方法做了很多次”。系统负责暴露这种跨步骤行为模式，是否换参数、换路线或继续执行，仍由模型判断。

第三个设计解决的是信息边界。Agent经常不是因为推理能力不够而犯错，而是因为系统给了它一份经过加工的信息，却没有告诉它信息被加工过。比如一次搜索实际找到几千条结果，为了控制Context只展示前100条，如果Tool Result只是安静地返回这100条，模型很容易把“我看到的全部”误认为“全部存在”。DeepSeek Harness的Output Retention因此明确区分：因为Context Budget没有全部展示，和上游数据本身就不完整，是两件不同的事。官方规定truncated只表示原本可获得的信息因为预算限制没有全部进入模型视图，Permission Failure、Provider Partial Failure、不可读文件或跳过二进制文件等异常不能被折叠进truncated。

这实际上是在给模型补充“认知边界”。搜索工具可以只把有限结果作为Preview交给模型，同时继续保留完整结果供后续读取，并准确说明有多少内容被省略；Shell操作如果因为Sandbox Policy被拒绝，也要明确告诉模型这是policy denial，而不是命令本身写错了。工具返回的不应该只有Data，还应该包含结果的完整性、失败性质和恢复路径。模型可以不知道某些信息，但不能在系统明知信息不完整时，还让它误以为自己已经看全。

第四个设计发生在Code Mode。传统Tool Calling往往是“模型调用工具A—拿结果—再次请求模型—调用工具B”，任务链越长，模型和工具之间的往返越多，中间结果也会持续进入Context。DeepSeek Harness的Code Mode允许模型通过run_code生成一段TypeScript，在程序里用系统生成的SDK组合多个agent-visible tools，把多轮工具编排压缩到一次代码执行中。效率提高之后，一个关键问题随之出现：如果模型能在一段程序里完成搜索、读文件、修改文件和执行Shell，会不会绕过原有权限系统？

DeepSeek的实现重点就在这里。Code Mode内部真正发生的子工具调用仍会重新进入Tool Registry的执行路径，通过nested executions形成独立的sub-dispatch并留下记录。也就是说，上层可以让模型用代码更灵活地编排动作，但真正对外部世界产生副作用的底层工具调用不能因为被包进run_code就失去治理边界。Agent自主性越高，底层的授权、Sandbox、Policy、Logging和Audit越需要保持稳定。

第五个设计是Shubham原文里最有传播力的一句话：“Kill the context, keep the workspace。”但它并不意味着DeepSeek Harness默认让所有长任务定期清空上下文，而是对应一个具体的Ralph fresh-agent workflow。Ralph是独立的Workflow Plugin，没有被硬编码进默认agent-loop。它把长期Objective拆成多个Round，每一轮启动新的Child Agent；新的Agent不继承父会话或上一轮Child的完整Conversation History，而只拿到不变的Objective、当前Round、共享Workspace以及上一轮的结构化Handoff。Handoff包含status、summary、evidence、next steps和blocker，并有明确长度上限。

这套设计真正重要的不是“清空Context”，而是重新定义长期Agent应该持久化什么。DeepSeek文档把Workspace视为跨Round的long-term memory：代码已经写进文件，就没有必要让下一轮继续携带写代码之前的所有讨论；测试结果已经产生，真正重要的是测试输出和当前代码状态，而不是生成这些结果之前的几十轮推理。于是Context更像“当前Agent此刻正在想什么”，Workspace更像“这个任务世界里已经真实发生了什么”。长期任务的核心问题也从“怎样让同一个模型记住越来越多历史”，转向“怎样让一个新的Agent根据共享工作状态和有限交接继续完成任务”。Ralph目前仍有边界，例如完成状态由worker自报，并非独立Evaluator认证，因此更适合被理解为一种可替换的编排策略，而不是长期Agent的最终答案。

把这5个设计放在一起，可以看到一条共同原则：让系统负责维护事实、边界和运行状态，让模型在这些事实之上做判断。Session Log让过去可还原，Repeat Reminder暴露重复行为，Output Retention说明信息边界，Code Mode把灵活编排和底层治理拆开，Workspace则让任务状态在上下文结束后继续存在。

如果用一句话概括：模型负责产生智能，Harness开始负责维护模型所在的“世界”。同一个模型放进不同Harness，看到的上下文、工具反馈方式、失败语义、权限机制和长期状态管理都可能不同，最终表现出来的已经是不同的Agent系统。DeepSeek目前仍把Harness标记为Developer Preview，核心插件和API还在快速演进，因此现在就把它定义成成熟统一平台还太早；但趋势已经很清楚——过去被视为Session、Context、Tool Wrapper、Guardrail、Permission、Sandbox和Workflow的一整层“外围工程”，正在成为Agent真正的运行系统。