“DeepSeek Harness”这个词最近在 Agent 和 Coding Agent 圈里快速升温，但它值得讨论的地方，并不只是又出现了一个代码助手。创源 AIGC 在本文中只作为在线接入节点观察，不是主角。DeepSeek Harness 试图把模型、工具、技能、会话、沙箱、存储、循环、调度和 UI 拆成可插拔组件，让 Agent 从一段对话变成一个可以持续运行的环境。本文会把它放回真实的 AI、AIGC 和 IT 工作流中观察：Harness 到底补上了哪一层能力，Coding Agent 为什么开始需要运行时，开源插件化会带来什么成本。文章适合使用过 Codex、Claude Code、VSCode AI 插件、Ollama 或 LiteLLM，想理解 Agent 基础设施而不是只比较模型回答质量的开发者。

本文依据 2026 年 8 月 15 日能够看到的公开仓库和开发者预览说明展开。DeepSeek Harness 仍处于快速迭代阶段，公开资料已经明确提醒可能存在兼容性破坏，因此下文将“当前可观察到的设计”与“未来可能实现的能力”分开，不把预览版的界面、插件名称或运行行为写成长期承诺。

一、大家谈的 Harness，究竟不是又一个模型

先把几个经常混在一起的词分开。模型负责根据上下文生成文本、代码或动作建议；工具负责读文件、执行命令、访问网页、调用 API；Agent Loop 负责决定下一轮要不要继续；而 Harness 则负责把这些部分放进一个可持续运行、可被控制和可被观察的环境中。

过去的 AI 编程体验更像一个增强版聊天框：开发者描述问题，模型给出代码，人工复制到编辑器里，再把报错贴回去。后来出现的 Coding Agent 开始拥有文件读取、Shell、搜索、计划和测试能力，能够在仓库中循环工作。但只要这些能力被硬编码在一个产品里，模型、工具和执行策略之间就会形成紧耦合。换一个模型可能要重写适配层，换一个沙箱可能影响所有工具，想把某个工具抽出来做自动化任务，也不容易复用。

Harness 的核心问题是：能不能把“模型会什么”和“运行环境允许做什么”分开。模型可以替换，工具可以替换，循环策略可以替换，甚至界面也可以替换，但它们仍然通过统一的服务和事件协作。这个思路并不等于 Agent 自动变聪明，它只是把 Agent 从一次性调用提升为一个可以编排的运行时。

这层区分对普通开发者也有直接意义。模型回答得不好，通常可以换模型、改上下文或调整任务拆分；运行时边界设计得不好，则可能让一个原本可控的错误变成文件破坏、凭据泄露或无限重试。前者属于质量问题，后者属于系统问题，处理方法完全不同。把两者放在同一张“模型效果”评分表里，会掩盖真正的工程风险。

还可以把 Harness 看成一条中间层：上面连接模型和 Agent 逻辑，下面连接操作系统、仓库、网络和外部服务。中间层要做的不是替每一方决定业务，而是翻译协议、维护状态、实施策略和保存证据。比如模型想调用 run_tests，Harness 需要把它转成受限进程；测试返回退出码后，Harness 再把结果包装成下一轮上下文。这个过程如果没有明确的事件和错误类型，开发者很难知道失败来自模型、工具还是宿主机。

从工程角度看，Harness 至少要回答六个问题：

1. 模型如何获得当前任务、历史事件和工具结果？
2. 工具调用如何被授权、记录、超时和取消？
3. 多轮循环什么时候继续，什么时候停止？
4. 会话如何恢复、分叉、搜索和回放？
5. 子 Agent 如何被调度，权限和上下文如何隔离？
6. 插件升级或替换后，旧任务还能否继续运行？

如果一个工具只解决了其中一两个问题，它更接近模型客户端或工具包；如果它把这些问题组织成可组合的运行时，才有资格被称为 Harness。DeepSeek Harness 受到关注，正是因为它把讨论重点从“哪个模型写代码更快”推向了“代码 Agent 应该运行在什么样的系统里”。

二、“一切皆插件”带来的不是口号，而是依赖关系

DeepSeek Harness 公开资料里最醒目的设计表达是“Everything is a Plugin”。它基于 Cordis 内核，内核主要负责插件的加载、卸载和依赖关系，Agent 的具体能力由插件提供。模型、工具、技能、会话、沙箱、存储、循环、调度和 UI 都可以成为插件，通过服务和事件协作。

这种结构与传统应用的最大区别，是能力不再只由主程序的类层次决定。开发者可以在配置层选择或替换某项能力，而不必修改 Harness 主源码。例如，一个团队可以让 Coding Agent 使用本地模型，把代码搜索和测试执行保留在本机，再把低风险文档整理交给外部节点；另一个团队则可以把同一套会话和轨迹能力接到不同的模型后端。

插件化的价值可以从三个方向理解。

能力的组合边界更清楚

传统 Agent 常把“模型、工具和提示词”揉在一个预设里。插件化以后，可以单独问某项能力属于哪个插件、依赖什么服务、是否可以替换。例如文件编辑器是工具插件，持久会话是存储或会话插件，循环策略是运行插件，权限控制则应该由沙箱或执行器承担。边界变清楚以后，开发者才有机会做最小化部署和逐项审计。

同一运行时可以承载不同 Agent

代码修复、测试生成、技术文档整理和线上事故分析，并不需要完全相同的工具集合。标准模式可以提供完整工具，极简模式只保留 Shell 和文件编辑，PTC 模式则让模型通过一段程序组合多轮工具调用，创造模式用于检查运行时和制作新的 Agent preset。它们共享底层 Harness，却拥有不同的能力面。

插件也会成为新的供应链

插件不是天然安全的。一个看似普通的搜索插件可能读取更多文件，一个日志插件可能把敏感内容写入外部服务，一个执行插件可能扩大 Shell 权限。插件化把替换成本降下来了，也把审计对象从“一个应用”扩展成“内核、官方插件、社区插件、依赖包和配置文件”的组合。团队若只看主仓库的许可证，却不检查插件的来源和权限，风险并没有消失。

因此，“一切皆插件”不应该被理解成“所有能力都可以随意安装”，而应该理解成“每项能力都需要独立描述、独立授权和独立验证”。在实际项目中，我会给插件补充最小元数据：输入数据等级、能访问的目录、能调用的命令、是否产生外部副作用、日志保存位置、替代插件和停止方式。元数据比宣传式功能列表更有助于做 IT 治理。

三、Coding Agent 为什么开始需要真正的运行时

早期的 AI 辅助编程主要在编辑器里完成。模型生成补全、解释函数或给出一个代码片段，编辑器负责展示，开发者负责复制和验证。这个模式的边界很清楚，但它无法很好地处理跨文件任务：分析调用链、修改多个模块、运行测试、读取失败日志，再根据结果进行第二轮修改。

当 Coding Agent 进入仓库以后，模型需要的不只是上下文窗口，还需要一个可控的运行环境。没有运行时，以下几件事很难稳定完成：

• 文件变更需要有明确的读写边界，而不是把整个仓库无差别暴露给模型。
• Shell 命令需要超时、取消和输出截断，否则一次卡住的进程会拖住整个任务。
• 工具调用需要被记录，才能知道模型为什么修改某个文件、用了哪些参数。
• 多轮循环需要停止条件，否则“再检查一次”可能变成无限调用。
• 会话需要支持恢复和分叉，才能把一次失败尝试与新的方案分开。
• 子 Agent 需要独立上下文和能力租约，不能默认继承主任务的全部权限。

这些需求已经超出了“调用一个大模型 API”的范围。它们涉及进程管理、文件系统、事件流、策略判断、日志存储和用户界面。Harness 的出现，说明 Agent 产品正在从提示词工程走向运行时工程。

运行时还承担“时间”的管理。一次代码任务可能持续几分钟，也可能因为测试、构建和人工确认延长到几个小时。上下文会变化，文件会变化，工具版本也会变化。如果没有会话快照和事件序号，模型看到的可能是一个已经过期的工作区。一个成熟的 Harness 至少需要区分任务创建时间、每次工具调用时间、人工介入时间和最终验收时间，才能在恢复或分叉时确定从哪个状态继续。

同样重要的是失败的可分类性。网络超时、命令退出码非零、权限拒绝、上下文过长、插件崩溃和模型拒答，不能都被包装成“Agent 失败”。不同错误需要不同恢复动作：网络问题可以切换节点，权限问题要停下来请求人工确认，测试失败可以回到修复环节，插件崩溃则应保留现场并中断任务。Harness 如果只提供一个通用异常，自动化程度越高，排查成本越大。

这里有一个很重要的区分：Harness 不等于 Agent 自主性。一个 Harness 可以提供很强的执行能力，但最终仍然需要模型、策略和人工共同决定做什么。更完整的运行时反而应该让“不能做什么”同样可见，例如禁止访问生产凭据、禁止修改迁移文件、禁止在测试未通过时提交变更。能力越多，停止机制越重要。

四、四种运行模式，反映的是四种风险取舍

DeepSeek Harness 当前公开的运行模式很适合用来理解 Agent 的能力分层。它们不是简单的界面主题，而是对“工具多到什么程度、自动化推进到哪一步”做出的不同取舍。

模式	主要能力	适合观察的问题	主要风险
标准模式	文件、Shell、检索、Skills、计划、目标、子 Agent 和工作流	完整 Coding Agent 如何协作	权限面较大，行为更难审计
PTC 模式	通过 Code Mode SDK 组合多步工具调用	工具编排能否减少重复往返	生成的程序可能放大单次错误
极简模式	持久 bash 与文件编辑	最小环境下的模型基准和可复现性	能力不足，需要人工补流程
创造模式	检查运行时、试验插件、制作 Agent preset	Harness 能否自定义和扩展	插件实验可能接触更多运行时能力

标准模式适合模拟日常开发，但不应该被误认为所有项目的默认答案。它拥有更完整的工具集合，也意味着需要更多权限隔离和操作记录。极简模式看起来功能少，却很适合做对照实验：同一个代码任务只给模型 Shell 和文件编辑，看看计划、搜索和子 Agent 这些能力到底带来了多少收益。

PTC 模式尤其值得观察。传统 Agent Loop 往往是模型调用工具、等待结果、再决定下一步；如果把多步调用组合成一段程序，模型可以在一次决策中完成过滤、遍历和汇总，减少不必要的往返。但这也改变了风险模型：原来一次工具调用的错误，可能被组合程序放大成几十次操作。因此，Code Mode 并不意味着可以绕过权限和审批，反而需要更细的资源限制、执行超时和结果核验。

创造模式则把 Harness 本身变成可探索对象。它让开发者能够检查当前运行时、试验 Cordis 插件并组合新的 preset。对于研究 Agent 基础设施的人，这种能力很有吸引力；对于普通业务仓库，创造模式应当与生产代码隔离，避免实验插件和工作目录发生意外交叉。

五、案例：用一个受限任务观察 Harness 的真实价值

为了避免把“能运行”误认为“适合研发”，我设计了一个小型接口修复任务。目标是给一个 FastAPI 服务增加分页参数，保留旧客户端行为，并补上回归测试。这个任务故意不复杂，因为我要观察的不是模型能否写出分页，而是 Harness 能否把整个过程组织成可复查的运行轨迹。

第一步：明确运行边界

我先准备一个独立工作目录，只放应用代码、测试文件和脱敏样例，不放生产配置、真实日志和数据库凭据。Harness 的工作模式选择极简模式，初始只提供持久 Shell 和文件编辑能力。这样可以观察在没有网页检索、Skills 和子 Agent 的情况下，模型是否仍然能完成基本分析。

任务说明中明确写出：

目标：为订单查询增加 updated_after 与 page_size 参数。
允许修改：app/orders.py、tests/test_orders.py、docs/orders.md。
禁止修改：迁移文件、部署文件、凭据文件和其他目录。
必须验证：旧参数行为、空结果响应、分页边界、API Schema、git diff --check。
停止条件：测试失败两次后暂停，输出失败原因，不继续修改文件。

这段配置的价值不在于写得漂亮，而在于让 Harness 有可以执行的边界。模型如果尝试读取不在白名单中的文件，工具层应当拒绝；命令超过预设时间，执行器应当中止并把状态写入轨迹；测试连续失败时，Agent Loop 应当进入暂停状态，而不是反复改写同一个函数。

第二步：让模型先观察，再允许写入

第一轮只给读取和测试能力，要求模型输出调用关系、兼容性风险和需要确认的事实。它可能会发现 page_size 的默认值在需求里没有定义，也可能发现旧测试把空数组作为固定响应。此时不能让模型用猜测填补空白，而是把问题写入待确认清单。

确认完成后，再启用文件编辑插件。每次写入都保存前后差异，并将修改文件、调用工具、命令输出和测试结果写入仅追加的会话事件流。这样，后续复盘时看到的不是一个“最终版本”，而是一条可以解释的轨迹：模型读取了什么，为什么提出修改，哪一步测试失败，人工在哪个节点改变了边界。

第三步：用轨迹而不是聊天记录复盘

如果只保存聊天文本，开发者很难还原一次 Agent 运行。聊天里可能有自然语言解释，却没有完整的工具参数、Shell 输出、上下文注入和子任务调度。Harness 的 Trajectory 视图和事件流设计，目标就是把这些运行事实串起来。

我会重点检查四类事件：

1. 输入事件：系统提示、任务说明、注入的文件片段和上下文版本。
2. 决策事件：模型提出的计划、工具选择和停止理由。
3. 执行事件：文件读写、Shell 命令、退出码、耗时和输出摘要。
4. 人工事件：批准、拒绝、修改边界、接受风险和最终验收。

这四类事件可以帮助区分“模型写错了”和“运行环境给错了上下文”。如果模型看到了过期接口定义，问题在上下文注入；如果工具返回了截断日志，问题在执行器；如果测试通过但文档没有更新，问题在验收流程。Harness 的价值不是让错误消失，而是让错误有位置可找。

第四步：与完整模式做一次对照

完成极简模式的任务后，再在隔离分支里使用标准模式。比较的指标不是生成速度，而是：修改文件数量、工具调用次数、人工纠正次数、测试失败类型、最终 diff 大小和轨迹是否容易理解。如果标准模式只是增加了许多没有被使用的能力，却没有减少返工，团队就没有必要把所有项目都切换过去。

这个案例还说明了一点：Harness 的评估对象不应只是模型输出。至少要同时看模型、工具、循环策略和权限配置。换一个模型可能改变代码质量，但如果 Harness 的停止条件、轨迹和回放能力稳定，整个系统仍然可以进行对比测试。

在实际记录中，我会给这次任务建立一份最小指标表：首次生成到可运行测试的时间、模型发起的工具调用次数、被策略拒绝的调用次数、人工介入次数、失败类型数量、最终修改行数以及回放时的差异。这里不追求把所有指标变成单一分数，而是观察哪些环节真正影响交付。比如，标准模式可能减少人工搜索，却增加了无关文件读取；PTC 模式可能减少往返次数，却让一次参数错误影响更多步骤；极简模式虽然慢一些，但轨迹更短、更容易审查。

如果团队需要把案例交给其他人复现，除了代码和测试，还应保存运行模式、插件清单、配置版本、模型别名和关键事件摘要。不要只保存最终 patch，因为 patch 无法解释为什么工具曾经读取某个文件，也无法说明某个测试失败是否被模型忽略。回放材料越完整，越能判断一次成功是流程稳定，还是偶然碰上了简单任务。

六、它与 Codex、Claude Code、Continue 和开源组件是什么关系

DeepSeek Harness 被讨论时，很容易出现“它要替代某某 Coding Agent”的说法。更准确的比较方式，是把不同工具放在不同层级上。

组件或产品形态	主要关注点	典型使用位置	与 Harness 的关系
Codex 类代码模型	代码理解、生成和修改建议	模型节点或代码助手	可以被 Harness 调用，也可以独立使用
Claude Code 类 Coding Agent	面向仓库的交互式开发体验	预置 Agent 产品	更接近带运行时的完整应用
Continue、VSCode AI 插件	编辑器内的补全和对话	IDE 层	可以作为工具入口，不等于完整 Harness
Ollama	本地模型运行	模型后端	可以作为本地模型服务节点
LiteLLM	统一 API、路由和调用管理	接入层或网关	解决模型调用接口，不负责完整 Agent Loop
DeepSeek Harness	插件化 Agent 运行时	组合模型、工具和运行模式	关注能力如何加载、协作、记录和回放

这张表并不是产品排名。一个团队完全可以用 Ollama 提供本地模型，用 LiteLLM 做接口适配，再把某个 Coding Agent 接入 Harness；也可以只运行一个编辑器插件，不引入完整运行时。关键在于团队是否需要跨工具的会话、权限、轨迹和循环管理。

DeepSeek Harness 的差异点，更多在“怎么组装 Agent”而不是“模型回答是否胜过所有竞争者”。公开资料里明确把模型也视为插件，这意味着它可以作为模型后端的上层运行时，而不是只能绑定某个模型。对于正在做内部 Agent 平台的开发者，这种分层思路值得研究；对于只想快速补一段函数的人，直接使用 IDE 插件可能更省维护。

同样需要注意，Harness 不能自动替代 API Gateway。LiteLLM 关注请求协议、模型别名、超时、限流和成本，Harness 关注会话、工具、循环和事件。两者可以组合，但职责不同。把所有问题都塞到 Harness 里，会让运行时承担计费、路由和组织级密钥管理，最后形成新的耦合。

七、开源 Harness 真正新增的工程责任

开源和插件化让开发者可以看到源码、修改组件和自建环境，但也意味着责任从服务商转移到了使用者。DeepSeek Harness 官方说明当前是开发者预览版，核心插件和基础 API 仍在迭代，兼容性破坏是需要预期的事项。这一点不能只写在 README 里，而应落实到部署和升级流程。

版本和插件兼容

不要直接把主分支当成稳定依赖。项目应锁定源码提交或明确的预览版本，同时保存插件清单、配置文件和运行样例。升级前用固定任务回放：同一份仓库、同一组脱敏输入、同一组测试命令，比较工具调用、文件差异和失败类型。如果事件格式或插件接口发生变化，先在隔离环境迁移，不要让生产任务边跑边升级。

沙箱和宿主机边界

Coding Agent 的风险往往不来自模型文本，而来自工具权限。Shell、文件编辑、网络检索和子 Agent 都可能扩大攻击面。沙箱应限制工作目录、网络出口、进程资源和凭据可见性；工具执行器应区分只读、可写、可提交和可发布，而不是只有一个“允许执行”开关。即使 Harness 提供了沙箱插件，团队仍然要检查具体平台上的实现和默认配置。

轨迹日志的隐私

运行轨迹越完整，排查能力越强，但泄露面也越大。系统提示、工具参数、文件片段、命令输出和上下文注入都可能包含密钥、客户数据或内部路径。日志应采用分级保存：任务编号、状态和校验摘要可以长期保留，敏感输入只在受控窗口内短期保存，密钥和完整客户数据不应因为“方便复盘”而进入轨迹。需要共享案例时，先做不可逆脱敏。

插件供应链

社区插件的代码、依赖和更新来源都要记录。安装插件前，至少确认许可证、维护者、发布版本、权限范围和是否包含网络请求；运行时限制插件能访问的服务，并对外部副作用做显式审批。一个插件可以是搜索工具，也可能悄悄变成数据出口。插件系统越灵活，供应链证据越不能缺席。

团队还需要为插件定义退出方式。一个插件停止维护、与新版本不兼容，或者被发现存在数据风险时，能否在不破坏历史会话的前提下移除它？比较稳妥的做法是让任务记录使用过的插件标识和版本，让核心工件不依赖插件私有格式；对外部调用则保留输入摘要和输出校验，而不是只保存一个无法解析的二进制结果。这样即使插件被撤下，旧任务仍然可以查看、导出和人工接管。

升级流程也不应只检查程序能否启动。一次完整的升级验收至少包括：旧会话是否能打开，工具权限是否保持原有边界，事件顺序是否稳定，错误是否仍能分类，极简模式是否可用，以及标准模式下的固定任务是否出现额外文件改动。对于开发预览版，兼容性检查本身就是使用成本的一部分，不能等出现事故后才补。

八、创源 AIGC 在 Harness 工作流中可以做什么

在这个架构里，创源 AIGC 更适合作为一个外部模型或内容处理节点，而不是 Harness 的替代品。它可以参与公开资料整理、非敏感需求改写、测试说明生成或接口兼容性观察，但会话、工具授权、沙箱、回放和验收仍应由应用侧或 Harness 侧负责。

在一次非敏感的 OpenAI Compatible API 接入观察中，测试记录使用的地址为：https://178.nz/yinc。这个地址只说明测试入口，不代表模型覆盖、价格、稳定性或服务承诺；是否纳入实际工作流，仍需根据数据等级、协议兼容性、上下文长度、延迟、成本和替代路径逐项确认。

如果把在线节点接入 Harness，至少要在插件或适配层完成四项隔离：

1. 输入过滤：只发送任务所需的最小上下文，禁止把宿主机路径和凭据一并传出。
2. 模型别名：在配置中使用逻辑名称，便于以后切换节点，不让任务绑定具体供应商字符串。
3. 输出落盘：保存响应摘要、模型版本和检查结果，不把未经审查的文本直接写入代码或发布流程。
4. 失败回退：网络超时、协议不兼容或服务变化时，回到人工、Ollama 或其他受控节点。

这也是创源 AIGC 与 DeepSeek Harness 的边界：前者可以是被调用的外部能力，后者解决的是能力如何进入 Agent 运行时。两者并非互相替代的关系。只要任务包和适配层保留清晰的输入、输出与停止条件，在线节点就可以被替换；如果把所有上下文和决策都留在某个外部窗口里，换不换 Harness 都会遇到迁移问题。

九、现在是否适合把 Harness 放进日常研发

DeepSeek Harness 的升温，说明开发者开始认真关注 Agent 的运行环境，而不只是模型排行榜。但“值得研究”不等于“所有团队都应马上迁移”。我会从四种场景判断是否值得投入。

适合做技术预研的场景，是团队正在建设内部 Coding Agent，已经遇到模型替换、工具权限、会话回放或多 Agent 编排问题。此时可以用极简模式和固定任务样例理解运行时，再逐步引入标准模式、PTC 和自定义插件。预研的目标应是验证架构边界，而不是追求一次任务的炫技效果。

适合小范围试用的场景，是公开或已脱敏代码、可回滚的测试仓库和有明确验收脚本的任务。先锁定版本，限制目录和网络，保存轨迹，设置失败停止条件，再让少量开发者参与。遇到兼容性变化时，可以删除工作目录并从任务样例重建，不影响生产代码。

暂时不适合引入的场景，包括生产发布、客户数据处理、无法脱敏的核心算法、没有沙箱的共享主机，以及团队没有维护插件和升级记录的人力。对于这些任务，模型可以提供建议，但不应让预览版运行时直接拥有副作用权限。

如果团队决定试用，可以把第一阶段限定为“只读观察”。让 Harness 读取一个脱敏仓库，生成计划和测试建议，但不允许写入、不允许访问外网、不允许调用子 Agent。第二阶段再开放受限文件编辑，所有差异必须经过人工审查；第三阶段才评估 PTC、子 Agent 或自定义插件。每个阶段都要有停止条件，例如轨迹出现未授权文件读取、插件权限超出清单、测试失败后仍然重复写入，便回退到上一阶段。

这种渐进方式的好处，是把“是否采用 Harness”拆成多个可以回答的小问题：插件接口是否足够稳定，轨迹是否真的帮助排查，极简模式能否满足基本任务，标准模式增加的能力是否值得维护。即使最后不采用完整方案，这些实验也能沉淀出更清楚的权限清单、测试样例和人工交接规范。

最后可以用一张检查表做决定：

• 是否能锁定 Harness 和插件版本，并准备升级回放？
• 是否能限制模型、工具、文件和网络的权限？
• 是否有人工确认点、停止条件和回滚路径？
• 是否能从轨迹中还原一次失败，而不是只看到最终答案？
• 是否有替代模型或人工流程，避免单节点依赖？
• 是否能把密钥、客户数据和敏感日志排除在会话记录之外？

如果这些问题还没有答案，先用现有 Codex、Claude Code、Continue、Ollama 或普通脚本把流程跑通，再评估是否需要引入完整 Harness。对 Harness 的正确期待，不是让 Agent 代替开发者承担责任，而是把模型、工具、权限、循环和证据放进一个可以被拆解、替换和复盘的系统。

换句话说，Harness 的第一价值不是让开发者少写几行代码，而是让一次 Agent 运行拥有清晰的边界、过程和出口。只有当团队能看见它做过什么、拒绝过什么、在哪一步停下，以及换掉某个插件后怎样继续，自动化才真正具备长期使用的基础。

这也是它与普通聊天窗口最根本的差别：窗口保存的是交流，Harness 保存的是一次可解释的运行。

结语：Harness 的价值，在于让 Agent 的“工作方式”成为工程对象

DeepSeek Harness 的讨论热度，背后反映的是 Coding Agent 正在进入基础设施阶段。模型仍然重要，但模型之外的运行环境同样决定了 Agent 能否在真实仓库里持续工作：工具是否可控，会话是否可恢复，循环是否会停止，插件是否可审计，轨迹是否能解释，升级是否能回放。

“一切皆插件”提供了一种有吸引力的组织方式，却不会自动消除复杂性。它把能力拆开，也把依赖、权限和供应链暴露出来。对开发者而言，最值得借鉴的不是某个模式按钮或某个模型名称，而是把 Agent 当成由模型、工具、策略、日志和人工验收共同组成的运行系统。

创源 AIGC 可以作为其中一个外部节点，DeepSeek Harness 可以作为组合这些节点的运行时，Ollama、LiteLLM、VSCode 和 Codex 则可以分别承担模型、接口、编辑器和代码处理角色。最终是否采用，仍然要回到任务风险、维护能力、迁移成本和验收标准，而不是只看一时的讨论热度。