异构智能体软件工程编排系统

一种不重新造通用 Coding Agent，而把 Codex、Claude Code、Gemini CLI、CodeBuddy 等完整 Agent Harness 作为异构执行资源，由统一 Supervisor 控制面按任务、能力、成本与证据进行编排的软件工程系统设想。

#synthesis #growing #ai #architecture #agent #mcp

[!info] related notes

所属 MOC: coding-agent-moc

相关概念: coding-agent-subagents、coding-agent-skills、mcp-in-agent-harness、multi-agent-orchestration-patterns

易混淆概念:

相关资源:

异构智能体软件工程编排系统

核心想法

这套系统更适合被称为 异构智能体软件工程编排系统（Heterogeneous Agentic Software Engineering Orchestration System），而不是简单的“自动编程系统”。

它的目标不是重新实现一个万能 Coding Agent，而是把不同厂商已经高度优化的 Agent Harness 当成可调度的异构执行资源，再由一个统一控制面负责理解用户目标、选择资源、分配角色、控制成本、维护状态、验证证据并向用户呈现结果。

最短表达：

让原生 Harness 负责“把任务做好”，让统一控制面负责“决定谁做、什么时候做、花多少资源、做到什么程度才算完成”。

这与 [[forgeflow|ForgeFlow]] 当前逐渐形成的方向一致：控制面不应该重复实现每家 Agent 的执行循环，而应该把不同执行环境纳入统一的软件工程生命周期。

先把几个容易混淆的词分开

LLM / Model

模型本身只负责推理与生成，例如某个 Codex、Claude、Gemini 或 DeepSeek 模型。它本身不等于 Coding Agent。

Agent

Agent 在模型外增加目标驱动的循环：观察环境、推理、调用工具、读取结果、继续行动，直到满足停止条件。

Agent Runtime / Agent Harness

Agent Runtime / Agent Harness 是更完整的“模型运行系统”，通常包含：

Agent loop
system instructions / policy
tool schema 与调用机制
文件搜索、编辑、Shell、Git 等内置工具
context management / compaction
session / checkpoint
permissions / approval
sandbox / execution environment
Skills / Rules / project instructions
MCP / Plugins / Extensions
Subagents
tracing / usage / telemetry
与模型配套的默认参数和交互协议

因此在这篇设想中，真正应该被调度的最小资源不是裸模型，而是一个 Harness Runtime Bundle。

例如：

CodeBuddy + DeepSeek V4.1 Flash + CodeBuddy tools + subagents + skills + MCP + sandbox

或：

Codex Harness + OpenAI coding model + Codex skills + MCP/plugins + worktree/sandbox

这比“把 DeepSeek API 塞进任意通用 Agent”更接近真实产品能力。

为什么原生 Harness 可能比“模型 + 通用 Agent”效果更好

这个判断有合理基础，但不能绝对化为“自家模型一定只能配自家 Agent”。更准确的说法是：模型能力和 Harness 之间存在明显的协同设计空间。

厂商可以同时优化：

训练与工具行为：让模型更熟悉函数调用、文件编辑、Shell、搜索、浏览器等 agentic 行为。
Tool schema / ACI：让工具名称、参数、错误反馈方式更符合模型训练时习惯的交互分布。
Patch / edit protocol：针对模型最稳定的代码编辑形式设计 apply-patch、文件替换或 diff 工作流。
Context management：针对模型特性决定哪些文件进入上下文、何时 compaction、如何保存摘要。
Reasoning / inference 参数：按任务类型选择 reasoning effort、缓存、长上下文策略或模型变体。
内置搜索与代码理解：优化 grep、索引、仓库探索、依赖关系分析，让模型少做无效读取。
Verification loop：决定什么时候跑测试、什么时候读取错误、什么时候停止继续探索。
Subagent policy：什么时候分派探索、规划、审查等子任务，以及给子代理什么模型和工具。
安全与权限：让模型知道哪些行为可以自动完成、哪些动作必须请求批准。
产品 Eval / Telemetry 闭环：厂商可以持续用真实 agent trace 发现模型与 Harness 的共同失败模式。

OpenAI 公开把部分 Codex 模型描述为“optimized for agentic coding tasks in Codex or similar environments”，就是这种模型与 agentic environment 联合优化的一个直接例子。

所以系统设计上不应该假定：

所有模型 × 所有 Harness = 等价

更合理的是维护经过验证的 Model × Harness Profile：

CapabilityProfile
- provider
- harness
- model
- supported tools
- skills / MCP
- sandbox
- context window
- reasoning modes
- code-edit capability
- review quality
- latency
- effective cost
- quota/account health
- known strengths / weaknesses
- validated task classes

三个主要平面

用户最初提出的三部分基本正确，但可以改成更专业的三个 Plane。

1. Harness Resource Plane：执行资源平面

这一层管理“谁真正干活”。

它不只登记模型，而登记完整执行资源：

Harness Resource
├─ Provider / Account
├─ Model
├─ Agent / Harness
├─ Tool Runtime
├─ Skills
├─ MCP / Plugins / Extensions
├─ Sandbox / Workspace
├─ Permission Profile
├─ Context / Memory Policy
├─ Subagent Capability
└─ Health / Quota / Cost / Performance Profile

典型资源可以是：

Codex Harness
Claude Code
Gemini CLI
CodeBuddy
OpenCode
其他支持 ACP / A2A / CLI / API 的完整 coding harness

这一层真正需要标准化的不是所有厂商内部实现，而是统一的外部资源契约：

start task
observe status
stream events
request/cancel
read artifact/evidence
resume/retry
report usage
report health

协议可以来自 ACP、A2A、API、CLI adapter 等，但系统内部最好收敛为自己的统一 execution contract。

2. Orchestration & Control Plane：编排与控制平面

这是系统主体，也是 Supervisor 所在的位置。

它负责：

理解用户 Objective
识别任务类型与风险
规划阶段：Research / Plan / Implement / Review / Repair / Verify
根据能力、成本、额度与健康度选择 Harness
为不同角色选择不同模型 / Harness
决定是否并行
维护 durable task state
处理 retry / fallback / recovery
控制 single-writer / workspace ownership
绑定代码 revision 与 review evidence
决定何时需要 Human-in-the-loop
保留 execution provenance

这部分最重要的设计原则是：

Supervisor 可以智能，但控制面不能只靠 Supervisor 的聊天上下文当系统真值。

比较合理的实现是：

Deterministic Control Plane
        │
        ├─ durable state / policy / budget / permissions
        ├─ route registry / capability registry
        ├─ evidence / provenance / lifecycle
        │
        └─ Pluggable Reasoning Supervisor
                └─ 用较强模型帮助分类、规划、replan、决策

也就是说，不建议再自己造一个“万能通用 Coding Agent”作为中心。更好的方式是：

自建薄控制面：掌握状态、资源、预算、安全与生命周期；
Supervisor 本身可替换：可以使用一个高质量 Harness / model 做 reasoning；
真正代码执行继续交给 provider-native Harness。

这样既不会把系统绑死在某一个厂商，又能利用优质 Harness 的推理与工具能力。

3. Interaction & Observability Plane：交互与可观测平面

UI 不应该只是聊天框，而应该同时承担“软件工程控制台”的职责。

可以分成几个主要视图：

Objective Workspace

用户和 Supervisor 的主要交互入口：

当前 Objective
当前 Plan
正在执行的阶段
当前 Agent / Harness / Model
关键决定
需要人工确认的 HITL 项

Resource Dashboard

展示每个执行资源：

Harness
Provider / Account
Model
Auth / Health
Quota
Cost / token usage
Latency
最近成功 / 失败
适合的任务类型
fallback 顺序

Execution / Evidence View

展示：

active tasks
subagents / workers
workspace / worktree
current revision
tests / CI
review finding
repair loop
delivery status

Cost & Efficiency View

这是这套系统很重要但很多 agent 产品较弱的一层：

每个 Objective 用了多少 token / quota / money
哪个阶段最耗资源
哪个 Harness 成功率更高
fallback 发生原因
同类任务历史平均成本
是否存在重复扫描、无效探索、过度 review

对额度有限的用户，这部分甚至应该与质量同等重要。

Skills 应该如何选择

不建议把所有 Skills 一股脑注入所有 Agent。Skills 本身也消耗上下文，而且越多并不一定越好。

更合理的是做 Capability / Skill Admission。

系统先分析：

User Prompt
+ Project Metadata
+ Tech Stack
+ Changed Files / Task Scope
+ Current Phase
+ Selected Harness

再选择：

Global Skills
  - 通用工程规范
  - Git / test / review discipline

Stack Skills
  - React / Next.js
  - Go
  - Python
  - PostgreSQL

Project Skills
  - BodySense contract rules
  - MemoFlow domain conventions

Task Skills
  - security review
  - performance profiling
  - migration
  - release

最终只向当前 Execution 投影必要能力。

这与 Coding Agent Skills、MCP 在 Agent Harness 中的配置架构的思路一致。

Subagent、Agent Team 与真正多 Agent 的区别

Subagent

Subagent 通常是：

Main Agent
  ├─ 子代理 A
  ├─ 子代理 B
  └─ 子代理 C

每个子代理有独立上下文，负责一个局部任务，然后把结果返回给 parent。

这是多 Agent 的一种，但更准确地说是 hierarchical manager-worker pattern。

它适合：

代码库探索
并行调查
多维 review
专门化任务
把大量临时上下文隔离在主会话之外

Agent Team

真正更接近“团队”的模式是：

Lead
 ├── Worker A ↔ Worker B
 ├── Worker B ↔ Worker C
 └── Shared Task State

Worker 不只向主 Agent 汇报，而能共享任务状态甚至直接通信。

Claude Code 已经公开区分这两种模式：Subagents 适合聚焦任务；Agent Teams 则是独立 session、共享 task list 与 inter-agent messaging。

多会话并行

还有一种并不算内部 multi-agent protocol：用户或 UI 同时启动多个完全独立 session，由人来当 Supervisor。这也是 Codex App 一类产品的重要模式。

现在主流 Coding Agent 是否已经能做到“规划 / 调查 / 实施 / 审查拆分”

可以做到相当一部分，但不等于已经完整实现这篇设想。

截至 2026-09：

OpenAI / Codex

OpenAI 已经把多项能力做成正式产品原语：

Codex App 支持多个 Agent 并行和 worktree 隔离；
Skills 可以根据任务自动或显式使用；
Agents API 提供由 OpenAI 托管的 Codex harness；
Agent 可以启用 multi-agent / subagents；
Agent Environment 可以包含 files、packages、plugins、skills，并支持 hosted / self-hosted 环境。

所以单一 OpenAI 生态内部已经非常接近：

Supervisor / root agent
  → research subagents
  → planning
  → implementation
  → review / verification

但它仍然主要是 同一供应商生态内部的 agent orchestration，并不是天然的跨 Claude Code / Gemini CLI / CodeBuddy 的异构资源调度中心。

Claude Code

Claude Code 同时有：

built-in / custom Subagents
独立模型与工具权限
Agent Teams
shared task list
teammate messaging
worktree / parallel execution 等模式

这已经明显超过“单主 Agent + 简单子任务”的阶段。

Gemini CLI

Gemini CLI 的 Subagent 有独立 system prompt、工具和 context window，并支持：

自动 delegation
custom local subagents
每个 subagent 单独配置模型
Remote Subagents
A2A protocol

这意味着它本身已经具有接入外部 Agent 的方向。

CodeBuddy

CodeBuddy 也提供：

built-in / custom subagents
project / user agent definitions
独立 context / tools / permissions
Skills
MCP tools
built-in Explore / Plan / General-Purpose 等角色
不同 built-in subagent 可单独映射模型

因此“一个主 Agent 根据阶段调用不同专长和不同模型”的想法已经在产品里出现。

那为什么仍然需要这篇设想里的系统

因为现有产品大多优化的是：

如何让自己的 Agent 生态做得更强。

而这篇设想关注的是：

如何在多个厂商完整 Harness 之间选择最合适、最便宜、当前还有额度、并且能满足质量要求的那个。

例如：

Research     → 便宜、快速、上下文隔离的 Explore Harness
Architecture → 高 reasoning 资源
Implement    → 对当前技术栈表现最稳定的 provider-native Coding Harness
Review       → 与 writer 独立、审查更强的 Harness
Repair       → 原 writer 或专门 repair route
Fallback     → 当前 quota / health 下的下一可用 Harness

这就是 heterogeneous orchestration 与单产品 multi-agent 的区别。

对“省额度多模型技巧”的分析

看到的技巧大意是：

主会话：中等成本模型
架构：强 reasoning 模型
调查：快速模型
实施：高性价比 coding 模型
审查：强审查模型
并行分包
大上下文
Bug 后切 Human-in-the-loop

它最有价值的地方不是具体模型名，而是背后的三个原则。

原则一：Role-based Model Routing

不要让最贵模型承担所有工作。

Explore ≠ Architect ≠ Implement ≠ Reviewer

不同角色需要的能力不同，所以可以使用不同价格/速度/智力的模型。

原则二：Context Isolation

让 Explore / Research Subagent 自己读取大量文件，最后只返回压缩结论，往往比把所有搜索结果塞进主上下文更省。

真正省 token 的核心经常不是“大上下文”，而是：

让低价值中间信息留在局部上下文，只让高价值结论进入主上下文。

原则三：在高歧义阶段增加 Human-in-the-loop

当项目已经复杂、业务决策不明确时，最浪费 token 的通常不是写代码，而是 Agent 不断：

猜意图 → 搜索 → 尝试 → 推翻 → 再搜索 → 再猜

此时人类快速确定业务方向，AI 做最小实现并立即反馈，确实可以显著减少无效探索。

这个技巧里需要修正的几点

1. 大上下文不是天然省额度

把 context 一律设为 300K 并不代表会更省。

大上下文的正确用途是“允许需要时容纳更多信息”，而不是每一轮都把整个仓库塞进去。

应该优先：

repository map
targeted retrieval
summary/cache
subagent context isolation
changed-file scope

2. 多 Agent 不是越多越省

多个 Agent 每个都有独立 context，天然会乘上 token 消耗。

并行只有在这些情况下划算：

子任务真正独立
可以缩短 wall-clock time
可以避免一个强模型串行读大量低价值材料
并行结果可以高度压缩后回传

对于同文件、强依赖、很小的 bug，单 Agent 通常更便宜。

3. “换根提示词”更适合抽象成 Policy Mode

不一定每次遇到 bug 都完全换 system prompt。

系统可以正式定义：

AUTONOMOUS
SUPERVISED
HUMAN_IN_LOOP
READ_ONLY_DIAGNOSIS

当风险、歧义或失败次数达到阈值后，由控制面切换模式。

这样比临时手工改 prompt 更稳定、可观测，也更适合自动系统。

4. Reviewer 必须尽可能独立

如果 Implementer 自己不断“审查自己”，很容易重复原来的假设。

更好的方式是独立 route：

Writer Harness ≠ Reviewer Harness

至少要做到独立 context；高价值任务还可以使用不同模型甚至不同厂商。

一个更适合额度有限用户的默认策略

User
 ↓
Supervisor（中等成本 reasoning，尽量短上下文）
 ↓
Scout / Explore
  - 便宜模型
  - read-only
  - 小而并行
  - 输出结构化摘要
 ↓
Plan
  - 只有复杂任务才调用强 reasoning
 ↓
Implement
  - 单 writer
  - 选择当前最有性价比且适配项目的 Harness
 ↓
Verify
  - deterministic tests first
 ↓
Review
  - 只有非平凡变更才调用强 Reviewer
 ↓
Human Gate
  - 高歧义 / 高风险 / 重复失败时介入

额外约束：

对每个 role 设置 token / time / retry budget；
不允许所有 worker 重复全仓扫描；
repository map 与稳定调查结果缓存；
默认单 writer；
read-only investigation 可以并行；
用测试、类型检查、CI 等确定性证据代替不必要的 LLM 再审查；
只有真正需要语义判断的问题才升级到昂贵模型。

Supervisor 应该使用“最强 Harness”还是自建通用 Agent

比较推荐第三种组合，而不是二选一：

自建 deterministic control plane + 可替换的 reasoning supervisor + provider-native execution harnesses。

理由：

完全使用某家 Harness 作为总控

优点：

开发快
内置 tools / subagents 很成熟
少造基础设施

问题：

容易 vendor lock-in
很难把其他 Harness 当一等资源
控制状态可能被聊天上下文绑架
provider 账号/额度失效时整个控制面一起失效

完全自己造通用 Supervisor Agent

优点：

最灵活
完全掌握协议和状态

问题：

会重新踩 context、tools、compaction、permissions、subagents、sandbox 等大量 Harness 工程问题
维护成本和 token 效率都可能不如厂商长期优化的原生 Harness

与 ForgeFlow 的关系

[[forgeflow|ForgeFlow]] 可以被看作这套设想的早期实验，但目标边界可以进一步收敛：

ForgeFlow ≠ 再造一个 Coding Agent
ForgeFlow = 软件工程 Control Plane + Harness Orchestration

长期更值得投入的是：

Harness adapter / normalized execution contract
resource registry
capability registry
health / quota / auth
role-based routing
cost-aware routing
skill admission
durable plan / recovery
independent review / evidence
HITL
operator UI / observability

而不应该重新实现各家已经做得很好的：

通用 Shell Agent loop
文件搜索器
基础 patch editor
通用 context compaction
通用 subagent runtime

当前最大的未决问题

统一协议是否成熟

不同 Harness 暴露方式仍然分散：

CLI
SDK / API
ACP
A2A
MCP tool
provider-specific server

系统需要一个稳定内部 contract，而不是让业务控制逻辑直接依赖每家协议。

如何量化“某 Harness 更适合某类任务”

不能只靠主观印象，需要积累：

task class
success rate
token / cost
latency
repair count
review finding
regression rate

形成自己的 task-to-resource empirical routing。

如何防止多 Agent 抵消节省的 token

必须有硬预算与 admission policy，而不是“能并行就全部并行”。

如何定义完成

Agent 自己说 done 不能成为真值。软件工程任务应该尽量落到：

test
typecheck
build
CI
exact revision
independent review
acceptance criteria

如何处理账号与羊毛额度

对于额度来源分散的场景，Resource Plane 需要把 account 也当一等资源：

Provider
  ├─ Account A: quota / expiry / health
  ├─ Account B: quota / expiry / health
  └─ API route C: cost / rate limit

路由时可以同时考虑：

quality × capability × marginal cost × remaining quota × expiry × reliability

这也是一般开源 Coding Agent 很少优先解决、但个人低成本系统非常现实的问题。

当前判断

这个方向并不是“必须现在立刻实现的新项目”，更适合作为一份长期架构假设保存。

2026 年各大厂商已经快速补齐：

subagents
agent teams
skills
plugins / MCP
worktree / sandbox
managed execution environment
multi-agent API

因此未来很可能出现更优雅的开源编排层，或者厂商直接开放足够标准化的 Harness API。

在那之前，最经济的策略是让 ForgeFlow 保持薄：只补自己真正需要、现有产品没有统一解决的跨 Harness 路由、成本、状态、证据与 UI，而不是和 Codex / Claude Code / Gemini CLI / CodeBuddy 比谁更会“当 Coding Agent”。

对当前想法的一句话总结

不是造一个更强的 AI 程序员，而是造一个能管理许多已经很强的 AI 程序员及其完整工作环境的软件工程控制系统。

2026-09 资料入口

OpenAI Agents API: https://openai.com/index/introducing-the-agents-api/
OpenAI Codex App: https://openai.com/index/introducing-the-codex-app/
OpenAI Agents API reference: https://developers.openai.com/api/reference/
Claude Code Subagents: https://code.claude.com/docs/en/subagents
Claude Code Agent Teams: https://code.claude.com/docs/en/agent-teams
Gemini CLI Subagents: https://geminicli.com/docs/core/subagents/
Gemini CLI Remote Subagents: https://geminicli.com/docs/core/remote-agents/
CodeBuddy Sub-Agents: https://www.codebuddy.ai/docs/cli/sub-agents

异构智能体软件工程编排系统

核心想法

先把几个容易混淆的词分开

LLM / Model

Agent

Agent Runtime / Agent Harness

为什么原生 Harness 可能比“模型 + 通用 Agent”效果更好

三个主要平面

1. Harness Resource Plane：执行资源平面

2. Orchestration & Control Plane：编排与控制平面

3. Interaction & Observability Plane：交互与可观测平面

Objective Workspace

Resource Dashboard

Execution / Evidence View

Cost & Efficiency View

Skills 应该如何选择

Subagent、Agent Team 与真正多 Agent 的区别

Subagent

Agent Team

多会话并行

现在主流 Coding Agent 是否已经能做到“规划 / 调查 / 实施 / 审查拆分”

OpenAI / Codex

Claude Code

Gemini CLI

CodeBuddy

那为什么仍然需要这篇设想里的系统

对“省额度多模型技巧”的分析

原则一：Role-based Model Routing

原则二：Context Isolation

原则三：在高歧义阶段增加 Human-in-the-loop

这个技巧里需要修正的几点

1. 大上下文不是天然省额度

2. 多 Agent 不是越多越省

3. “换根提示词”更适合抽象成 Policy Mode

4. Reviewer 必须尽可能独立

一个更适合额度有限用户的默认策略

Supervisor 应该使用“最强 Harness”还是自建通用 Agent

完全使用某家 Harness 作为总控

完全自己造通用 Supervisor Agent

推荐组合

与 ForgeFlow 的关系

当前最大的未决问题

统一协议是否成熟

如何量化“某 Harness 更适合某类任务”

如何防止多 Agent 抵消节省的 token

如何定义完成

如何处理账号与羊毛额度

当前判断

对当前想法的一句话总结

2026-09 资料入口