企业官网建设流程全解析

最近把 DeepSeek Harness 的插件列表完整刷了一遍，发现官方已经把 Codex 和 Claude Code 收编为子智能体适配器了，再配合 Git 工作树和思考翻译两个新能力，多智能体协作的体验彻底变了个样。这三个功能放在一起，刚好把智能体编排里最头疼的三件事一次性理清：谁来执行、在哪执行、为什么这么执行。这篇文章我先把更新背后的设计逻辑拆开讲，然后给出可以直接上手的配置方式、目录规划思路和排查技巧，最后聊一聊这套组合机制还能往哪些方向扩展。

1. 这次更新到底动了什么：三个核心能力的全景拆解

先别急着看配置，得先把这次更新放在一个更大的背景下去理解。DeepSeek Harness 本质上是一个围绕推理模型构建的智能体编排层，它做的事情是：把复杂任务拆解成若干子任务，然后让不同能力的“执行单元”去分别处理，最后由主控模型汇总结果。这个思路本身并不新鲜，但难点在于执行单元之间的协作成本——每个子智能体都有自己的上下文窗口、工具调用方式和输出格式，协调起来非常麻烦。

1.1 三个关键词背后的真实改动

这次更新其实是在三个不同的层面同时动手：

• 适配器层：把 Codex、Claude Code 纳入官方插件列表。表面上看只是多了两个预设配置，实际上是把两套完全不同的智能体调用协议做了统一封装。以后在主控模型里下发任务时，不需要自己分别处理两家的消息格式、会话管理和错误返回，全部通过统一的子智能体接口调度。
• 工程层：引入 Git 工作树（worktree）支持。这个解决的是并行执行时的文件系统隔离问题。以前多个子智能体同时跑同一个仓库，改一个文件撞车是家常便饭。工作树能让你从同一个仓库里拉出多个独立的工作目录，每个目录对应一个分支，互不干扰。
• 可观测层：新增思考翻译功能。推理模型在生成回答之前会有一长串内部推理过程，也就是俗称的思维链。思考翻译做的事情是把这段内部推理翻译成人类能直接理解的自然语言摘要，并且在任务日志里展示出来。

1.2 面向谁的价值

这次更新的目标用户非常清晰，不是所有用 DeepSeek 的人都需要，而是这些场景的人收益最大：

• 同时使用多个 AI 编程助手，想用统一调度层管理它们的人
• 需要让多个智能体并行处理同一个项目的不同模块，但是被文件冲突搞到崩溃的人
• 用推理模型跑长任务，但无法判断模型“为什么中途改方案”的人

我自己这几周用下来的最大感受是，工作树和思考翻译组合起来，能把一个原本需要人工盯守的并行开发任务，变成可以放手的自动化流水线。接下来我按三个功能分别讲。

2. 子智能体接入：Codex 和 Claude Code 的适配器原理与配置

先讲子智能体接入，因为这是整个更新的骨架。DeepSeek Harness 一直以来的设计理念是“主控负责思考，执行单元负责干活”，这次新增的两个适配器，本质上是把市面上最主流的两个编码智能体工具接进了这个体系。

2.1 适配器模式的设计逻辑

为什么不直接在代码里写两套专门对接逻辑，而是要做成“适配器”？这里有个很重要的工程权衡：接插件模式的维护成本远低于硬编码。

假设你直接在 Harness 核心代码里写死对 Codex 的调用，那么一旦 Codex 的接口发生变化，整个系统都要跟着升级。但用适配器模式，核心调度逻辑只面向一个抽象的“子智能体接口”，具体怎么和 Codex 通信、怎么解析它的回应，全部封装在插件内部。官方插件列表的本质，就是一套经过测试的适配器实现，你不需要自己逆向协议、猜测参数格式了。

我提一个关键细节：插件列表里的配置不只是 API 地址和模型名称，还包括了任务描述模板和输出解析规则。因为 Codex 和 Claude Code 的输出风格差异很大，Codex 倾向于输出标准化 JSON 格式的执行计划，Claude Code 则更偏向在对话流里逐步给出操作结果。Harness 的适配器会把这些不同格式统一转成内部的任务结果对象。

2.2 配置示例与任务流转

配置方式在 Harness 的plugins.json文件里进行，大体长这样：

{ "plugins": { "codex": { "type": "subagent", "adapter": "@official/codex-adapter", "model": "codex-1", "worktree": "auto", "max_iterations": 8, "routing_rules": { "priority": ["code-generation", "refactoring"], "blocked": ["security-review"] } }, "claude_code": { "type": "subagent", "adapter": "@official/claude-code-adapter", "model": "claude-code-2", "worktree": "auto", "max_iterations": 12, "routing_rules": { "priority": ["exploration", "test-writing"], "blocked": ["production-deploy"] } } } }

配置里最重要的两个参数是worktree和routing_rules。worktree设为auto表示这个子智能体每次执行任务时，Harness 自动从主仓库拉出一个独立工作树，任务结束再合并回主分支。routing_rules则是任务路由策略，告诉主控模型什么类型的子任务优先派给哪个子智能体。

实际的调度流程是这样的：

1. 主控模型（DeepSeek 推理模型）拿到一个人类指令，比如“优化某个模块的查询性能”。
2. 主控模型将这个指令拆解为多个子任务：分析瓶颈、生成优化代码、编写测试、回归验证。
3. 调度器根据routing_rules将代码生成任务分配给 Codex，将测试编写任务分配给 Claude Code。
4. 两个子智能体在各自独立的工作树中执行，完成后把结果汇报给主控。
5. 主控模型汇总所有子结果，做最终判断：通过则合并；不通过则派回对应子智能体重做。

这个流程里最有价值的点在工作树隔离。以前我试过让多个智能体在同一个目录干活，结果一个智能体刚改完的公共工具函数，被另一个智能体的全量格式化覆盖掉，排查浪费了半天。用工作树之后，这类问题基本绝迹。

2.3 和核心模型的分工边界

很多刚接触这套架构的人会问一个问题：DeepSeek 自己也能写代码，为什么还要接 Codex 和 Claude Code？

我的理解是这样的：主控模型的强项是推理、规划、判定，它擅长在信息不完整的局面下做出合理的决策；而 Codex 这类编码智能体的强项是在既定的任务边界内高效产出代码，它们经过大量代码语料训练，对常见框架的写法、命名惯例、API 调用方式更敏感。让主控模型既做规划又写大量代码，容易在长上下文里把推理能力和生成能力搅在一起，影响判断质量。分工之后，主控模型的上下文更干净，它只关心“要什么”“做得怎么样”，具体的“怎么写”交给执行单元。

不过这里也有个边界问题要强调：不是所有任务都适合派给子智能体。比如涉及核心业务逻辑的小改动，或者需要强领域知识的重构，直接在主控模型里做反而更稳。routing_rules 里的blocked字段就是干这个事用的，务必把高风险操作纳入黑名单。

3. Git 工作树：并行开发与隔离任务的底层工程保障

如果说子智能体接入解决的是“谁来执行”的问题，那么 Git 工作树解决的就是“在哪执行、怎么并行”的问题。这一节我详细讲工作树的使用逻辑，因为这是这次更新里最容易被低估、但实际价值最高的部分。

3.1 为什么是 git worktree 而不是分支切来切去

先给不熟悉工作树的读者补个基础概念。正常情况下，一个 Git 仓库在你本地就是一个目录，你在这一个目录里切换分支，代价是工作区内容跟着变化。如果当前有未提交的修改，切换分支还得先 stash 或者 commit，非常麻烦。而git worktree允许一个仓库同时关联多个工作目录，每个目录可以检出不同的分支，共享同一个 Git 元数据。

用一句生活化的话解释：以前你是一个人在一间办公室里干活，换项目就得收拾桌子；工作树是给你配了多间独立办公室，每个项目一间，互不影响，而且共用一个行政体系（Git 仓库）。

在 Harness 的并行场景里，这个能力直接改变了下发任务的模式：

• 没有工作树时：串行执行，等一个智能体完成并提交，再让下一个上，耗时随子任务数量线性增长。
• 有工作树时：并行执行，调度器根据子任务数量自动创建 N 个工作目录，各个智能体同时开工，最后统一合并。

3.2 工作树的初始化与清理实战

虽然 Harness 配置里可以设置worktree: auto，但我还是建议了解手动创建工作树的具体命令，方便排查问题和自定义目录规划。

假设你得主项目在~/projects/demo-app，现在要让一个子智能体去处理 feature-a 分支：

cd ~/projects/demo-app # 为 feature-a 创建一个独立的工作目录 git worktree add ../demo-app-feature-a -b feature-a # 查看当前仓库关联的所有工作树 git worktree list # 该工作树用完后，先确保没有未提交改动 git -C ../demo-app-feature-a status # 提交或推送到远端后，删除工作树 git worktree remove ../demo-app-feature-a # 如果远端分支还需要保留，手动删分支 git branch -d feature-a

这里有一个很容易踩的坑：如果工作树目录里有未提交的修改或被 untracked 文件占用，git worktree remove会报错，提示目录不干净。Harness 的 auto 模式在任务结束时会自动处理提交和清理，但是如果子智能体异常退出，工作树可能会残留下来，所以你最好定期检查git worktree list，把明显废弃的工作树清理掉。

另一种常见做法是在 Harness 配置中指定worktree_dir前缀：

{ "worktree_dir": "/tmp/harness-worktrees/", "worktree_mode": "parallel", "max_parallel": 3, "cleanup": "after-task" }

max_parallel参数一定要根据自己机器的内存和磁盘空间调，不是越大越好。每个工作树都是一份完整的工作区拷贝，如果项目里 node_modules 或 build 目录特别大，开十个工作树能把磁盘塞满。

3.3 多智能体并行时的目录规划

我在多次实操中摸索出一个比较稳定的目录规划策略，分享给大家参考：

• 任务类型决定工作树分支命名：代码生成任务用feat/xxx，bug 修复用fix/xxx，探索分析用explore/xxx。这样从分支名就能看出子智能体的历史任务，排查问题时非常有帮助。
• 共享依赖目录要放工作树外部：比如 Python 项目的.venv、Node 项目的node_modules，如果每个工作树都复制一份，既占空间又慢。把这些目录设置到公共路径，然后在工作树里用符号链接指向它们。Harness 的插件配置里可以设置external_links，把指定目录排除在复制范围之外，自动创建软链。
• 合并策略要统一：并行工作树各自完成后，合并回主分支时尽量用git merge --no-ff保留合并记录，方便日后回溯。Harness 的调度器支持配置merge_strategy，我一般设为no-ff-squash，既能保留主线整洁，又不丢失分支细节。

这套并行工作流的代价是需要更强的磁盘空间和更规范的分支管理意识，但换来的执行效率很值。实测下来，一个需要 30 分钟串行完成的三个子任务，用工作树并行可以压到 12 分钟左右。

4. 思考翻译：让推理模型的黑盒思考变白盒

第三个更新点是思考翻译，乍一听有点抽象，但用起来非常上头。这个功能解决的是长任务执行中“不可预测性”的问题。

4.1 什么是思考翻译

推理模型在回答复杂问题时，内部会有一个逐步推理的过程，这个过程在技术上叫“思维链”（chain-of-thought）。早期模型会把这段过程原封不动输出出来，用户能看到模型在“想什么”，但是原始思维链有两个问题：

1. 可读性差：思维链里有大量中间推理片段、不确定的假设、自问自答，直接看非常费劲。
2. 有干扰性：有时候模型会在思维链里提到一个错误的假设，然后在最终回答里纠正过来。这时候如果用户看到了错误的链路，会对最终结果产生怀疑。

思考翻译做的事，是把原始的思维链内容重新组织成结构化的、面向人类阅读的摘要，提炼出三个关键信息：当前任务的完成状态、刚刚做了哪些关键判断、下一步计划是什么。Harness 会把这些翻译结果写到任务日志中，方便你实时跟踪。

打个比方：原始思维链相当于一个程序员一边敲代码一边自言自语：“不对，这里应该用哈希表，但内存会不会爆？算了先试一下，哦不行，还是用索引吧。”思考翻译则是他在项目周报上写的：“本周完成了数据检索模块重构，决定从哈希表改为索引方案，主要考虑内存稳定性，下周开始测试性能。”

4.2 实现路径与可用模式

Harness 里思考翻译有两个实现路径：

• 端侧翻译：直接在本地对思维链做文本摘要，速度快，不消耗额外 API 调用，但是摘要质量取决于本地模型的大小，词句会比较干巴。
• 主控模型翻译：把原始思维链丢回主控模型，让它生成翻译结果。质量高，但会占用主控模型的上下文窗口，同时增加推理成本。

我建议默认用端侧翻译，只有在排查复杂问题时才切换成主控模型翻译。因为复杂任务中真正需要你看的思考细节是很少的，大部分中间过程翻译出来也是噪音。

配置上大致是这样：

thinking_translation: mode: local # local | central detail_level: summary # brief | summary | full include_reasoning: false output_format: markdown

detail_level这个参数很关键：

• brief：只显示任务当前状态和下一步计划，适合日常盯进度。
• summary：额外包括关键判断和改动理由，适合需要评审中间结果的时候。
• full：接近原始思维链的完整翻译，token 消耗最大，建议只在对某个智能体的行为产生疑惑时才用。

4.3 什么时候值得开、什么时候建议关

思考翻译不是一个“永远开着就好”的功能，我整理了一个开关策略供参考：

我个人的使用习惯是：并行任务跑起来之后，我会开一个持续轮询日志的窗口，只看summary级别的思考翻译。如果发现某个子智能体的翻译结果里出现“计划变更”或者“风险”关键词，再针对性调到full模式看细节。这种分层观察法，既不会淹没在信息洪流里，又能及时抓住关键决策点。

这里提醒一句：思考翻译严格来说是消耗 token 的。特别是central模式，每翻译一次都要把思维链内容重新发给主控模型，一条长任务跑下来，这部分的开销可能比子智能体执行本身的调用还高。所以除非任务真的需要深度干预，否则不建议长期开central + full。

5. 常见问题与排查技巧实录

功能再多，用起来总会遇到各种奇怪的问题。这一节我整理了自己这段时间踩过的一些坑和排查思路，按出现频率排序。

5.1 子智能体接入失败的排查顺序

最典型的表现是：任务发下去了，调度器一直报“subagent unavailable”或者“adapter handshake timeout”。

遇到这类问题，我的排查顺序是固定的：

1. 先确认适配器版本。插件列表里的适配器会随 Harness 主版本迭代，如果你还在用旧版的 Harness 主程序，新适配器可能要求更高版本的 API 接口，直接不兼容。优先升级整个 Harness，而不是单独替换插件。
2. 检查本机网络代理设置。Codex 和 Claude Code 作为外部智能体服务，它们的 API 调用路径不同于 DeepSeek 主控模型。如果本机的代理规则只放行了主控模型的域名，子智能体的请求可能被路由策略拦下。排查时把子智能体的 API endpoint 加入代理白名单，而不是一刀切关掉代理。
3. 看错误日志里的握手阶段。Harness 的子智能体通信有明确的握手阶段：建立连接、交换元数据、加载上下文。日志里卡在哪个阶段，问题就在哪。卡在交换元数据阶段，通常是配置文件里的模型名和实际 API 提供的模型名对不上；卡在加载上下文阶段，通常是工作树创建失败。

这里我要强调一个很容易忽略的细节：Codex 和 Claude Code 的模型名并不是固定的字符串，它们会随服务端版本更新有细微变化。你在插件列表里看到的只是一个别名，实际调用时 Harness 会请求服务端的最新版本列表做映射。如果你手动改过配置里的model字段并且写死了旧名称，那就会握手失败。所以不要随便改这个字段。

5.2 工作树和子模块冲突处理

如果你的项目是 monorepo 结构，里面还嵌套了子模块（submodule），工作树功能会遇到一些额外麻烦。

最大的问题是：git worktree add默认不会同步子模块的检出状态。也就是说，新建的工作树里子模块目录可能是空的，子智能体一旦访问子模块里的文件，就会报类似“No such file or directory”的错误。

处理办法是新建工作树后立即执行子模块初始化：

git worktree add ../demo-app-feature-a -b feature-a git -C ../demo-app-feature-a submodule update --init --recursive

如果你用的是 Harness 的worktree: auto模式，记得在 Harness 配置里开启submodule_autoload: true，它会在工作树创建后自动做这一步。

另外，一个项目里可能有多个子模块，不同子智能体负责的子任务可能只涉及其中某一个子模块。这种情况下 I 建议在任务前缀描述里写清楚：“只工作在/libs/utils子模块内，不要触碰其他子模块”，能显著减少误操作的概率。

5.3 思考翻译输出异常

思考翻译偶尔会输出一些莫名其妙的内容，常见的有两种：

一种是翻译结果里出现大段的原文照抄。这是因为端侧翻译模型对某些长思维链做了降级处理，不再真正理解，而是截取了原文片段。遇到这个情况，把detail_level调低一档，翻译压力变小后反而会恢复正常。

另一种是翻译结果和最终执行结果对不上。比如翻译里写着“正在重构缓存层”，但最终代码改动里完全没有相关变化。这通常不是翻译的问题，而是思维链本身就“跑题”了。我看到这种情况时，第一反应是检查任务上下文是不是太模糊，导致子智能体在思考阶段做了和最终行动不一致的规划。解决方案是在任务描述里加上明确的验收条件，让模型在思考阶段就锁定行动边界。

5.4 脏状态残留的清扫技巧

最后分享一个非常实用的清扫技巧。并行工作树跑多了，仓库的git worktree list会变得惨不忍睹，大量prune不掉的工作树目录躺在那里。

如果你确定所有工作树的变更都已经合并或不需要了，可以批量清理：

# 先查看所有工作树 git worktree list --porcelain # 清理被删但残留记录的 worktree 元数据 git worktree prune # 强制删除指定工作树目录 git worktree remove --force <path>

对于 Harness 异常退出留下的工作树，我一般直接手动删目录，再执行git worktree prune清理元数据。不过要小心，真的不要手滑删掉还有未合并变更的工作树，先逐个确认状态再动手。

6. 这套组合还能怎么用：扩展场景与落地建议

功能本身讲完了，最后一部分聊一聊这套组合机制在更多场景下的玩法，算是给你一些扩展思路。

6.1 多模型评审流程

Codex 和 Claude Code 不只是干活工具，也可以当评审角色用。我试过一种做法：让 DeepSeek 主控模型先完成一版实现，然后分别给 Codex 和 Claude Code 下发“代码评审”子任务，并且刻意不告诉它们这是谁写的。

两个子智能体在各自工作树里独立分析，给出的评审意见角度完全不同——Codex 更关注算法复杂度和边界条件，Claude Code 更关注可维护性、命名和测试覆盖。主控模型综合两份意见后，自己再做一个终审。这种多模型交叉验证的方式，比单个模型自评要可靠得多。

实现上并不复杂，只需要在任务定义里把输出格式设成模板化的评审报告，并且在工作树上设成只读模式（readonly: true），防止评审过程中意外改动代码。

6.2 自动化长任务流水线

工作树 + 多子智能体 + 思考翻译组合起来，可以做自动化长任务流水线。

比如一个完整的“从需求到测试”的流水线：

1. 主控模型读取需求文档，拆分成 N 个功能点。
2. 调度器为每个功能点创建独立工作树，Codex 负责实现，Claude Code 负责写测试。
3. 实现完成后，Harness 自动执行测试命令，收集失败信息回传主控模型。
4. 主控模型根据失败信息决定是返回修改，还是继续集成。
5. 全部通过后，调度器按依赖顺序把工作树合并回主分支。

这套流水线不需要写复杂的外部 CI 脚本，所有的编排逻辑都在 Harness 内部完成。思考翻译在这里的作用是让“无人值守”变得安全：你可以定期扫一眼日志里的翻译摘要，确认每个子智能体都走在正轨上，而不是等到最后合并时才发现全错了。

6.3 团队内部协作规范

如果一个团队多人同时使用 Harness，建议提前定好工作树的命名规范和插件配置的版本管理规则。

我见过最混乱的情况是：某个人本地跑了一个工作树任务，忘记移除，导致远程分支上多出一个奇怪的 reference。后来我们定了几条硬性规则：

• 工作树分支命名必须带创建日期和任务编号，比如feat/20250115-task-1024
• Harness 的插件配置文件纳入 Git 管理，修改必须走 review
• 所有max_iterations不允许私自调大，防止子智能体陷入无限循环

这些规范看起来琐碎，但能在关键时刻节省大量沟通成本。自动化程度越高的系统，越需要明确的地基。

6.4 进一步扩展的可能性

如果你对这套架构有更长时间的规划，还可以考虑两个扩展方向：

一是把子智能体适配器做成自定义插件。官方的 Codex 和 Claude Code 插件只是一个开始，Harness 的插件接口是开放的，你可以把团队内部已有的命令行工具封装成子智能体。比如把内部构建工具暴露成一个子智能体，让主控模型根据任务自动调用构建和发布流程。

二是把思考翻译的输出沉淀成可检索的知识库。既然每次任务都有结构化的思考翻译日志，定期汇总这些日志就能形成一份“项目决策史”。以后遇到类似问题，主控模型可以优先检索历史决策，避免重复试错。

这两个方向都需要一定的开发投入，但是在当前多智能体工具快速迭代的背景下，早一步把这块能力跑起来，长期收益会很明显。

说回这次更新本身，我最满意的一点是它终于把智能体协作从“玩具阶段”推向了“工程化阶段”。适配器定好了执行边界，工作树解决了并行冲突，思考翻译补上了可观测性，三者缺一不可。如果你现在手头正好有多智能体并行协办的需求，照着这个配置思路先跑一个最小闭环试试，大概率能感受到效率上的明显差别。