DeepSeek Harness 两天冲上 10 万 Stars：AI Agent 的真正前沿，已经从模型转向基础设施

当一个大模型项目在不到两天内获得超过10万个GitHub Stars时，整个技术社区的目光都会被吸引过去。DeepSeek Harness（简称 dsh）正是这样一个项目——它不仅是一个代码助手，更是为构建和运行AI Agent而设计的开源运行时。真正值得关注的不是它的Star增长速度，而是它所代表的行业方向：AI Agent的下一个竞争前沿，已经从模型本身转向了模型周围的运行时基础设施。

插件化架构：重新定义AI Agent的运行时设计

DeepSeek Harness的核心设计理念非常简单却极具力量：一切皆插件。从模型适配器、工具注册表，到会话日志、Agent Loop，再到文件系统访问、子进程执行、沙箱、审批策略、权限控制和持久化机制，全部作为可替换能力暴露出来。这种架构解决了一个根本问题：LLM本身只是一个“生成下一步动作”的模型，真正让它成为可工作的Agent，还需要一个运行时负责提供上下文、工具、状态、权限和反馈。Harness回答的关键问题是：模型能看到什么？能调用什么？允许改动什么？改动是否需要审批？失败后从哪里恢复？

从「agent.ts大文件」到可组合基础设施

很多团队的第一个Agent原型都是这样的结构：构造提示词→调用模型→解析工具调用→执行命令→把结果追加回上下文→重复循环。这种方式在原型阶段完全够用，但生产需求很快会超出它的承载能力：远程沙箱、多租户工具集、兼容不同模型接口、会话重放、后台任务抽象、结构化遥测、可恢复Shell、文件系统权限策略、审批节点、断点续跑……最终Agent Loop可能膨胀成数千行难以维护的代码。 DeepSeek Harness引入的Profile和Bundle机制提供了优雅的解决方案。Profile定义了一种命名的Agent/runtime组合，Bundle则是一组可分发的配置和插件。内置的Web Profile提供浏览器界面，Headless Profile则提供不启动Web服务器的一次性Runner。配置按层叠方式组合，开发者可以通过`dsh --profile web --dump-config`查看最终解析后的真实系统配置，这解决了动态组合系统最怕的「源配置看起来没问题，但组合出来的runtime不知道是什么」的痛点。

配置驱动的部署形态：Profile与Bundle机制

DeepSeek Harness对turn和step的区分值得技术人员重点关注。一个step对应一次模型请求及该请求触发的工具调用，一个turn则可以包含多个step。关键事件（turn/start、step/start、step/end、turn/end等）会写入session log。这种设计的核心原则是：凡是会影响模型所见内容的东西，都应该可以从持久化状态中重建。这为重放、调试、会话分叉、断点续跑、生成完整记录、遥测、审计和确定性测试提供了坚实基础。这些能力在Agent只做对话时显得无聊，但当Agent开始执行真实文件修改和命令执行时，它们会迅速从「锦上添花」变成「能不能上线」的基础条件。

Agent Loop的工程化：事件化Session模型

工具作为插件的设计同样蕴含了精妙的工程思考。首先，依赖必须显式声明——插件声明`export const inject = ['tools']`，Cordis会等待依赖的服务存在后再加载插件，避免运行时「猜」自己需要什么。其次，工具的数据值和模型展示是分离的——标准化输出值与专门面向模型的renderer不需要绑定为同一种格式。第三，插件卸载时注册的内容会自动移除，还可以注册可逆效果来处理需要显式清理的资源。这套生命周期管理在热重载、租户专属工具、动态模型路由等场景中至关重要——没有生命周期的插件系统，最终很容易变成内存泄漏和状态污染的源头。 配置错误应该在组合时失败，而不是运行40分钟后失败。任何可能被不同部署设置成不同值的东西都应该是配置项，插件可以导出类型化配置schema，非法配置应该在插件加载时而非任务执行阶段暴露。这是一条朴素却关键的生产原则。

如有侵权，请联系删除。