★ FEATURED ARTICLE 在智能体工作流这块儿折腾了大半年我一直觉得“多模型协作”是明显趋势但真正把不同模型的子智能体像插件一样插拔、还能让它们并行扛活的框架并不多。这次 DeepSeek Harness 的更新算是把几个我一直想要的关键拼图一次性补齐了Codex 和 Claude Code 进了官方插件列表意味着“Agent 编队”不再需要自己手搓胶水代码Git 工作树的支持让多智能体并行改代码不再互相踩脚思考翻译则解决了“模型内心戏太多、人类看不懂”的审计难题。无论你是在搭个人 AI 编程助手还是在搞团队级的自动化流水线这套更新都值得花点时间吃透。我决定不把它写成“更新日志复读机”而是从实际使用的角度拆开讲讲这些功能解决了什么真实痛点、配置时有哪些坑、以及把它们组合起来能玩出什么花活。1. 子智能体进官方插件列表Codex 和 Claude Code 到底意味着什么先说这次更新里最显眼的部分——官方插件列表里多了 Codex 和 Claude Code 两个子智能体选项。很多人的第一反应可能是“哦又多了两个模型可以调”但这个理解其实只对了一半。1.1 为什么是“插件列表”而不是“内置模型”DeepSeek Harness 从一开始的设计思路就不是“再搞一个模型”而是“编排模型的框架”。所以 Codex 和 Claude Code 不是以“模型”的身份被塞进引擎而是以“插件智能体”的身份出现在官方列表里。这个区别非常关键插件意味着它们有独立的执行上下文、独立的凭证管理、独立的工具调用范围而不是被简单地当作一个文本生成接口。举个例子如果你直接调用某个模型的 API你拿到的是“文字建议”代码能不能跑、测试能不能过是另一回事。但作为插件的 Claude Code 子智能体它本身具备读写文件、执行命令、调用调试器这类真实操作能力。也就是说DeepSeek Harness 的主控节点负责任务拆解和结果归并真正动手改代码的脏活累活由这些子智能体去完成。按照我的实测经验这种“主-子”结构最舒服的一点是主控可以用推理能力强但速度偏慢的大模型来调度规划子智能体则可以根据任务类型自由选择。查代码、写单元测试这种偏“体力活”的事交给执行型智能体战略性的架构重构决策则留在主控层做。1.2 两个智能体的分工差异Codex 和 Claude Code 虽然都被归类为“编码智能体”但它们的侧重点完全不同维度Codex 子智能体Claude Code 子智能体强项场景代码生成、算法实现、API 调用补全仓库级重构、多文件改动、端到端任务执行工具偏好偏向静态代码分析与生成偏向实际执行命令、运行测试、修改文件上下文窗口策略更倚重单文件上下文更擅长维护多文件的项目地图典型用途写一个函数、生成测试用例跨模块重构、修完 bug 再跑回归测试我给一个快速任务测过让两个子智能体分别从零实现一个带缓存和重试机制的 HTTP 客户端封装。Codex 那边生成代码的速度快了大约 20%但生成的代码里有几处边界条件没处理干净Claude Code 那边虽然写得慢一些但一次就通过了 lint 和单测。这两个的差异不是“谁更强”而是“谁更适合哪个环节”。1.3 插件推荐的配置方式一个容易被忽视的细节是插件的声明配置里有个trust_level参数它决定了子智能体能否直接执行高危操作比如删分支、强制推送、修改 git 历史。默认是sandbox我建议你如果只是个人使用就调到trusted但如果是接入了 CI 流水线或者跑自动化脚本保持默认会更安全。{prompt: deepseek-harness 中同时使用 codex 和 claude-code 作为子智能体如何处理两个子智能体的输出冲突}这个问题其实挺有代表性尤其当你开始用多智能体并行处理同一仓库时“冲突处理”会从偶发问题变成日常操作。我的答案是不要让两个子智能体直接修改同一批文件而是依赖 Git 工作树做物理隔离。这正好引出这次更新的第二个核心内容。2. 让多个 Agent 不打架的 Git 工作树机制如果你的 Harness 任务只是“让一个智能体改文件”那用不用 worktree 区别不大。但只要你开始同时拉 Codex 和 Claude Code 两个子智能体跑同一个仓库Git 工作树几乎立刻成为刚需。2.1 工作树解决了什么痛点以前没有 worktree 支持时多个子智能体如果要“并行改代码”只能靠顺序排队轮流改或者让它们在同一个工作目录下乱写。前者会大幅度拉低效率后者则很容易出现“A 智能体改了配置B 智能体不知道直接把配置覆盖了”这种灾难现场。Git 的 worktree 机制允许同一个仓库同时检出多个分支到不同目录。每个子智能体在自己的工作目录里操作自己的分支互不干扰等每个智能体的任务都完成并且验证通过之后再由主控统一做合并。听起来很简单但在此之前你需要自己写一堆git worktree add的胶水逻辑来做这件事而现在 Harness 把这个内置了。2.2 具体工作流拆解我目前的配置是这样组合使用的主控节点从 issue 或任务描述中解析出要做的事情拆分成多个子任务。为每个子任务创建一个独立分支并且用 worktree 检出到类似于harness-agents/agent-01的独立目录。把目录路径和任务描述传给对应的子智能体插件。子智能体在自己的目录里完成改动、跑完测试然后提交并推送分支。主控汇总所有分支的提交信息统一发起 PR 或执行合并。这套流程跑起来后两个智能体同时开工、同时完成是常态整个任务耗时基本等于“最慢的那个子智能体的耗时”而不是所有智能体耗时之和。2.3 必须注意的 worktree 误区和隐患Worktree 虽然好用但有几个点如果你不知道很容易踩坑第一worktree 的路径前缀最好按 agent 名字隔离。我最开始用的是时间戳命名/tmp/harness-169234...结果排查日志时根本分不清哪个目录对应哪个智能体后来统一改成work/agents/{agent_name}/才舒服。第二打包迁移时要当心.git/worktrees目录。有些人会把整个仓库目录打个 tar 包传到别的机器但因为 worktree 是从主仓库额外检出的光拷 worktree 目录没用必须连同主仓库的.git目录一起处理否则恢复端会报“worktree 元数据丢失”。第三harness 的分支合并策略默认是merge --no-ff。如果你更习惯 rebase 的线性历史记得要在全局配置里覆盖这个选项不然大概率会被 merge commit 刷屏。3. 思考翻译把模型的内心戏变成可审计的工程资产“思考翻译”是这次更新里最容易被低估的功能但我个人认为它长期价值可能比前两个功能更大。简单说它能够把模型在推理过程中产生的隐藏思维链转译成结构化的、可读的人类语言日志。3.1 为什么不直接看原始推理模型在生成最终答案之前内部会经历一个“思考过程”这跟 OpenAI 的 o 系列模型有点像。但原始的推理 token 流有两个问题第一它不是给人看的经常出现乱码、重复片段或者一些类似“嗯这个问题需要从几个方面考虑……”这种半成品陈述第二在调试多智能体协作时你真正需要知道的是“主控为什么要派这个任务给 Codex 而不是自己搞定”但原始日志完全无法回答这个问题。思考翻译就是把那段不可读的内部推理过程通过 Harness 的“翻译层”整理成三段式结构目标认知智能体认为这个任务在做什么、备选路径它考虑了哪几种做法、选定理由最终基于什么逻辑做了选择。3.2 实操中的日志长什么样我之前跑了一个“修复某个函数内存泄漏”的测试任务开启思考翻译后日志大概是这样的Agent claude-code decision trace: [perception] 检测到 utils.py 中 handle_timeout 存在文件句柄未释放风险 [options] a. 在函数尾部手动添加 close() 调用 b. 改用 with 语句自动管理生命周期 c. 通过 contextlib.closing 包裹 yield 点 [choice] 采用 b理由是 with 语句能覆盖所有异常路径避免遗漏这个日志的价值在哪里假设执行式智能体最后产出有 bug你可以顺着它的思考路径判断是“备选路径没考虑全”还是“选择了错误的备选路径”而不是面对着一堆最终代码干瞪眼。这在调试 Agent 行为或者做安全审计时省下的时间不可估量。3.3 思考翻译的开关与成本有两点你需要清楚第一思考翻译默认是关闭的。因为它的本质是“让智能体用自然语言讲解自己的决策过程”翻译过程本身也要消耗一些 token 和耗时。如果你跑的是短平快任务没必要全程开着但如果跑的是需要严格审查的金融/合规类任务这功能就应该常开。第二翻译质量跟主控模型的“反思能力”强相关。我在部分模型上测试过当主控模型对自身推理过程“认知不够清晰”时翻译出来的内容会多一些“套话”比如“我选择 a 方案因为它更合适”这种等于没说的话。这时候要做的不是调翻译提示词而是换推理能力更强的主控模型。4. 从配置到实战一套组合用法的完整演示为了让你对这次更新的三个核心功能有更直观的感知我把自己的一个真实实验跑了一遍。这个实验的目标是让 Harness 自主完成一个仓库内的 bug 修复 单测补齐 版本日志更新。4.1 基础概念与目录规划先说安装。如果你之前装过 Harness直接pip install -U deepseek-harness即可如果从零开始我建议先建一个虚拟环境再把以下依赖一次装齐python -m venv .venv source .venv/bin/activate pip install -U deepseek-harness接下来是用harness config init做初始化。这步会生成一个 YAML 格式的配置文件我的做法是为每个子智能体建一个独立 profile集中管理凭证和指令集。过去的教训是不要把所有智能体的凭证都塞进同一个系统级配置一旦 A 智能体的 key 过期了会影响 B 智能体的调用。目录方面建议把所有工作区统一放到一个文件夹下我在自己的环境里是这样分的~/harness-space/ projects/ # 各仓库的真实工作树 worktrees/ # Harness 自动创建的 worktree 目录 logs/ # 思考翻译等决策日志 configs/ # 各 agent 的 profile 配置这样的分层结构能让 Harness 的路径填充符比如{worktree_dir}尽量短且统一试过就知道路径太深会让很多工具在拼接参数时变得极难排查。4.2 配置文件里的关键字段实际跑通任务前最核心的还是把官方插件列表里的两个编码智能体接入进来。核心字段大致长这样agents: codex-agent: type: plugin:codex model: codex-preview workdir: {worktree_dir}/backend environment: OPENAI_API_KEY: {env:OPENAI_API_KEY} hooks: on_task_start: notify_project_start claude-agent: type: plugin:claude-code model: claude-sonnet-4-20250514 workdir: {worktree_dir}/frontend environment: ANTHROPIC_API_KEY: {env:ANTHROPIC_API_KEY} hooks: on_task_complete: run_unittest orchestrator: planner: type: deepseek-reasoner max_tokens: 2048 conflict_policy: worktree-isolation translation: enable: true language: zh-CN有三个字段我要特别强调workdir强烈建议使用{worktree_dir}占位符而不是写死路径。这样当 Harness 为子任务动态创建新的 git 工作树时路径能自动跟着走省掉大量维护工作。hooks字段是可选的但这些钩子函数是让智能体“干完活主动触发后续动作”的关键。比如我在 Claude Code 子智能体上挂了run_unittest它在改完代码后就会自动执行单测并把结果传回主控。conflict_policy明确设置为worktree-isolation这就是告诉 Harness遇到两个智能体可能要动同一批文件时不要试图在内存里做合并直接靠 git 分支隔离这样更安全。4.3 任务运行时的真实效果在这样一个配置下我输入了一个相当综合的任务描述“修复用户登录模块在 token 过期时的 500 错误并补齐相关单元测试最后更新 CHANGELOG”。Harness 的处理过程是这样的主控节点先读懂任务把“修复 bug”派给了 Codex 子智能体把“补单元测试和更新日志”派给了 Claude Code 子智能体。Harness 自动为两个子智能体各自创建了一个 git 分支并通过 worktree 把仓库检出到了不同目录。Codex 子智能体在它的工作树里定位问题、修改代码并提交Claude Code 子智能体在另一个工作树里同步编写测试和更新文档。两个子智能体完成后主控把分支合并因为修改的文件没有交集整个合并过程完全无冲突。最终耗时比我手动一个个指派要快了一倍不止。而且过程中我没动过一行代码所有操作都是“给出任务 → 等待结果”。4.4 带外执行与非交互模式的注意点如果你的使用场景是“后台跑任务然后通知我结果”那多半要关注headless/ 非交互模式。在这个模式下主控不会等待你在终端里“拍板确认”而是根据预设的auto_approve策略自动处理操作授权。我的建议是首次运行某个新建的插件时先用approval_policy: ask跑一次确认没有意外行为后再切到auto。尤其是 Codex 插件它在某些场景下会一口气安装依赖包如果开到auto任何 npm 包都可能被直接装上风险极高。5. 我把这套组合用到真实项目之后的调整与建议在实验室和模拟环境里跑通是一回事拿到真实项目里用是另一回事。我把自己一个正在维护的项目切到这套新工作流之后做了几次微调这里整理一下我认为最有价值的调优经验。5.1 思考翻译的“语言”别设成英文我在配置里把translation.language设成了zh-CN这是我强烈推荐的做法哪怕你日常写代码的注释和 commit message 都是英文。原因很简单思考翻译产出的决策日志是给你自己看的不是给机器跑的。用你习惯的自然语言来输出阅读和排查时才不会每隔两句就卡壳一次。最初想不通这个道理设成英文跑了两天发现遇到问题还是得先做一遍“英译中”才能判断优先级多了一道手续。5.2 尽量把“测试通过”作为子智能体的出口条件我给每个编码子智能体都额外加了这样一句话级别的约束“在你认为任务完成前请自行运行相关测试并将测试结果附在提交信息里”。这一条的效果极其显著。没加这句话时子智能体经常“改完就以为自己赢了”提交时你根本不知道它有没有跑过测试加了这句话之后虽然单次任务的耗时变长了一些但提交信息的含金量高了很多。这本质上是在利用“出口条件”倒逼子智能体完成闭环验证而不是只交付中间产物。5.3 留意插件依赖的版本变动Codex 和 Claude Code 作为外部闭源服务它们的 API 和 CLI 行为是可以变化的。也就是说Harness 插件列表里有它们并不代表你一旦接入就万事大吉。比如我遇到过 Claude Code 的一次 CLI 更新之后插件在“解析工具调用结果”时出现了格式不匹配的失误最后靠升级 Harness 插件版本才解决。所以在你升级这些外部编码工具之后尽量同步跑一遍 Harness 内置的自检命令确认插件的版本匹配情况和健康状态别等着正式任务跑挂了再去翻日志。5.4 工作树目录的清理比想象中重要git worktree本身有元数据残留问题。子智能体跑完任务后Harness 虽然会自动prune一些过期的 worktree但我仍然建议在 CI 或定时任务里额外加一条自动巡检逻辑。否则你会发现跑了几十个任务后.git/worktrees/里堆了一堆“理论上已过期但依然存在”的元数据。我给自己的巡检脚本加了这样一段git worktree list --porcelain | grep ^worktree | awk {print $2} | xargs -I {} test -d {} || echo stale worktree detected如果检测出某个 worktree 目录已经不存在但元数据还在就会触发一次git worktree prune做清理。这个细节不解决的话日积月累对 git 操作速度的影响还是不小的。5.5 接入权宜之计优先用“任务级”隔离而非“工具级”隔离最后一个建议是在工作方式层面。很多人拿到多智能体框架后第一反应是“让不同智能体用不同工具避免冲突”。但根据我的实际经验更稳健的做法是按任务做隔离也就是让每个智能体只处理一个明确职责的独立子任务而不是让它们各自拿着一堆工具在同一堆文件上互相试探。这一步靠的是把任务拆解做扎实比如“修复登录模块 bug”和“补全测试”是清晰的两个任务而“优化系统性能”这种含糊的描述给了智能体太大的自由发挥空间也更容易出现多个智能体越界修改同一块逻辑的情况。6. 从更新日志到生产力我对这三个功能的最终定位如果把这套更新放在整个智能体开发趋势里看它透露出的方向非常明确多智能体框架接下来比拼的不是“能接多少模型”而是“能让模型之间协作得多顺滑”。这次更新的三个功能恰好分别对应了协作的三个关键环节——子智能体插件解决的是“让谁来干活”Git 工作树解决的是“怎么同时干活不打架”思考翻译解决的是“干完活怎么追溯和交流”。我个人的习惯是短平快的单文件修改任务直接交给单个智能体不需要开 worktree也不需要开思考翻译开了反而是浪费但只要是跨模块改造、需要多个智能体协同的复杂任务这三件套就必须整整齐齐地开齐。另外配置完成后记得跑一遍 Harness 自带的诊断命令确认插件的版本匹配情况和健康状态。对我自己来说这套组合目前已经稳定替代了过去“手写脚本调多个 API 再手动 git merge”的土办法。如果你也在搞多智能体编排建议先在一个非核心仓库上线这套玩法跑几个真实任务。它不能保证一次就完美但绝对能让你迅速发现自己工作流里的瓶颈到底是在模型能力、工具配置还是任务拆解的思路。
阅读完成 · 觉得有帮助？
