AI 编程工具正在重塑研发流程，但"让 AI 随便写"带来的混乱也正在倒逼团队寻找工程化约束。在 云栈社区 的技术讨论中，越来越多的一线开发者开始意识到：真正可落地的 AI Coding，不是比谁的模型强，而是比谁的约束体系更扎实。
让"好代码"的标准写进系统里，让 AI 在约束下自己干活。
内容概览
本文聚焦两个核心问题：工具在 Harness 体系中的功能定位，以及它们在实际场景中如何相互配合，后续工程化流程如何搭建。
- 第一部分：理念与架构 — Harness Engineering 核心理念、6 大支柱详解、AI Coding 一体化架构
- 第二部分：落地实操 — 3 阶段实施路线图、工具配置详解、日常开发 SOP 与反模式
- 第三部分：工具对比 — 主流 AI 工具 QoderCN vs ZCode vs DeepSeek、六大支柱能力映射、开源方案统一选型
- 第四部分：总结 — 团队协作红线、合规性自检、知识飞轮与持续优化
第一部分：理念与架构
理解 Harness Engineering 的核心理念与 AI Coding 一体化架构设计
什么是 Harness Engineering？
2026 年 2 月，OpenAI 发布文章《Harness Engineering: Leveraging Codex in an Agent-First World》，给出了一个值得细读的案例：
一个 3 人工程师团队（后来扩到 7 人），在完全禁止手写代码的条件下，用 AI Agent 在 5 个月内写了 100万+行代码，合并了 1,500个 Pull Request，效率提升了约 10倍
这组数字意味着什么？
- 平均每人每月产出 4万+ 行代码
- 每天合并 10 个 PR
- 传统开发模式下，这几乎是不可能的
但关键不是"让 AI 随便写"，而是建立了一套完整的 Harness（约束体系）。
Harness 的词源与核心公式
Harness = 马具（缰绳、马鞍、马镫）。
一匹没驯服的马力量很大，但没法耕地、运货、上战场。给它配上马具，才能精准控制方向、分配力量、确保安全。
AI 也一样：
Agent = Model + Harness
- Model（模型） — 提供智能：理解指令、生成文本、做出决策
- Harness（约束） — 让智能变成生产力：工具调用、权限校验、状态持久化、执行编排
你写的所有代码、配的所有规则，都是 Harness 的一部分。
为什么需要 Harness？
没有 Harness 约束的 Vibe Coding（氛围编码），走的是一条死路：
起步极快 → 中期混乱 → 后期崩盘
具体表现为三个致命问题：
🏚️ 架构混乱 — Agent 喜欢走捷径，功能 A 用库 X，功能 B 用库 Y，完全没有分层概念。后果： 换底层逻辑整个项目大改。
📉 上下文雪崩 — 项目超过 50 个文件后，Agent 开始"忘事"，命名不一致、逻辑矛盾。后果： 项目越大，Agent 越蠢。
🔒 可维护性丧失 — 开发过程是黑盒，人没参与思考，只有 Agent 知道代码怎么来的。后果： 几千行"垃圾代码"不如重写。
Harness 解决什么问题？
Harness Engineering 就是要解决上述三个问题，它提供四大核心能力：
🛡️ 安全边界 — 权限控制（AI 能访问哪些文件、能执行哪些操作）；审计日志（记录 AI 的每一次决策和操作）；拒绝追踪（AI 拒绝执行时的原因可追溯）。
👁️ 可观测性 — Token 计数（监控每次交互的成本）；成本追踪（量化 AI 辅助开发的投入产出）；决策日志（AI 为什么做出某个选择）。
🔧 可靠性 — 重试机制（失败时自动重试或降级）；降级策略（高级功能不可用时回退到基础模式）；确定性兜底（关键路径有明确的人工接管点）。
📦 扩展性 — 工具生态（MCP 连接外部系统）；技能系统（Skills 封装领域经验）；多 Agent 协调（复杂任务拆解给不同角色）。
Harness 的 6 大支柱
OpenAI 把 Agent 的运行环境拆成 6 个支柱，每个支柱在开发规范中都有对应的工具和实践。
| 支柱 |
核心问题 |
| 📋 上下文管理 |
AI 的上下文窗口有限且贵，怎么让 AI 在对的时间看到对的信息？ |
| 🔧 工具系统 |
AI 怎么触达代码仓库之外的真实世界？怎么具备特定领域的专业能力？ |
| 🎭 执行编排 |
怎么让 AI 按部就班而不是乱写一气？怎么让多个 Agent 角色配合？ |
| 💾 状态与记忆 |
怎么让 AI 在长周期开发中保持一致性，不"忘事"？ |
| 📊 评估与观测 |
怎么验证 AI 生成的代码是不是靠谱的？质量如何衡量？ |
| 🛡️ 约束与恢复 |
怎么防止 AI 越界操作？出错了怎么快速恢复？ |
支柱一：上下文管理（Context Architecture）
核心问题：AI 的上下文窗口有限且贵，怎么让 AI 在对的时间看到对的信息？
上下文管理的目标不是"给 AI 更多信息"，而是"在对的时间给对的信息"。
📑 渐进式披露 — 写一个约 100 行的 AGENTS.md 目录文件，指向 ARCHITECTURE.md、Rules 等细分文档。原则： 别一次灌给 AI 几千行规范。
📝 结构化规范 — 把需求和设计决策写进 Git 仓库（requirement.md / task.md），变成 AI 随时能调取的"长期记忆"。
🔀 变更隔离 — 用 changes/ 目录把"增量变更"和"存量代码"隔开，减少对现有逻辑的误伤。
📦 知识分层 — Skills 信息分三层按需加载：描述 → 指令 → 详细步骤。省 Context，提高加载效率。
📚 知识库挂载 — 团队 Wiki、代码仓库、业务文档挂载为知识库，AI 对话时自动或手动引用，获取业务上下文。
🤖 代码知识化 — 基于代码库自动生成结构化知识文档（AI Wiki），AI 不用逐文件阅读就能理解项目全貌。
OpenAI 踩过的坑： 早期试过"一个巨大的 AGENTS.md"，失败了。正确做法是拆成多个专注文档，用目录索引串起来。
支柱二：工具系统 — MCP
核心问题：AI 怎么触达代码仓库之外的真实世界？
MCP（Model Context Protocol） 是 AI 的"感知触手"，让 AI 能连接外部数据源。
🗄️ DB MCP 作用： 自动读取实时数据库 Schema。场景： 避免 AI 写出不存在的字段，生成准确的 SQL。
📖 Knowledge Base MCP 作用： 挂载团队内部文档。场景： 让 AI 有业务上下文，理解领域术语。
🔌 API MCP 作用： 实时查询其他服务接口定义。场景： 微服务联调时，确保接口参数一致。
🔧 运维 MCP 作用： 接入 CI/CD、监控系统。场景： AI 直接触发构建、查看日志、分析告警。
核心比喻： MCP 是开门的钥匙 —— 没有 MCP，AI 就是闭门造车。
支柱二：工具系统 — Skills & 知识库
Skills 是业务逻辑、领域知识和执行 SOP 的封装，让 AI 从"什么都会一点"变成"某个领域的专家"。
🔧 工具接入类 — 封装内部工具链的接入规范。例：rainbow-config 按标准流程接入七彩石配置中心。
📝 代码生成类 — 固化特定模式的代码生成逻辑。例：按团队架构规范生成 CRUD 模块。
🧬 元技能类 — 让 AI 能自我扩展。例：skill-creator 教 AI 根据代码创建新 Skill。
知识库 是让 AI 从"通用模型"变成"懂业务的助手"的关键：
- iWiki 文档库 — 业务规范、技术方案、API 文档
- 代码库知识 — 公共组件正确用法
- AI Wiki — 基于代码库自动生成的结构化文档
- 自定义文件 — 需求文档、设计稿、会议纪要
三者关系： MCP 是钥匙，Skills 是进门后做的事，知识库是进门前读的说明书。三者缺一不可。
支柱三：执行编排与多 Agent 协作
核心问题：怎么让 AI 按部就班？怎么让多个 Agent 角色配合完成复杂任务？
团队应该遵循 "3+1 Phase" 标准化工作流，每个阶段由不同角色的 Agent 负责：
- P1 计划 — Plan 模式生成 requirements.md，人工审核后创建 task.md
- P2 编码 — 加载 Rules 和 Skills，调用 MCP 工具实现代码
- P3 交付 — AI 自动做规范合规检查，代码逻辑审查后合入
- P4 沉淀 — 自动把 Spec 归档，更新项目知识库
多 Agent 角色定义：
🧠 Planner（规划者） — 职责：理解需求、拆解任务、生成方案。加载的 Harness：Plan 模式 + 项目 Spec。输入：自然语言需求描述。产出：结构化的 requirements.md。
⚡ Generator（生成者） — 职责：按方案写代码、写测试。加载的 Harness：Rules + Skills + MCP。输入：审核通过的任务清单。产出：源代码 + 单元测试。
🔍 Evaluator（评估者） — 职责：代码审查、规范检查、测试验证。加载的 Harness：Rules + 验收标准。输入：待合入的代码变更。产出：通过核查的 PR。
📁 Archiver（归档者） — 职责：归档变更、更新知识库。加载的 Harness：归档脚本 + Git。输入：已合并的需求。产出：持久化的知识资产。
实际操作： Plan 模式做架构分析 → Agent 模式做具体实现 → AI CR 做交付把关
支柱四：状态与记忆
核心问题：怎么让 AI 在长周期开发中保持一致性，不"忘事"？
Harness 通过四层记忆体系解决这个问题：
短期记忆 → 当前会话上下文（单次对话） — AI 在当前对话中能看到的所有信息。一旦对话关闭就丢失，直接影响当次任务执行质量。
中期记忆 → Memories 功能（跨会话持久化） — 开发者偏好的编码风格、项目技术栈约定、踩过的坑等，对话结束后主动保存，下次自动加载。
长期记忆 → Git 仓库中的 Spec 文件（项目全生命周期） — 架构选型、接口约定、业务规则等关键决策持久化到 Git，任何 Agent 任何时候都可读取。
变更记忆 → Spec Deltas（changes/ 目录，单次变更周期） — 记录"这次改了什么、为什么改、影响范围是什么"，完成后自动归档到长期记忆。
设计哲学： 不信任 AI 的"记性"，而是用工程手段把记忆分层管理——短期的靠上下文，中期的靠 Memories，长期的靠 Git，变更的靠 Spec Deltas。
支柱五：评估与观测（4 层）
核心问题：怎么验证 AI 生成的代码是不是靠谱的？质量如何衡量？
Harness 定义了四层递进式的质量评估闭环：
L1 语法 → 编译通过、Lint 检查 — 最基本的门槛，过滤语法错误、类型不匹配、导入缺失等低级错误。完全自动化，零人工介入。
L2 逻辑 → 单元测试通过 — 验证"代码做了对的事"——输入输出符合预期、边界条件处理正确、异常路径有兜底。
L3 规范 → 符合 Rules 约束 — 通过 AI CR Agent 自动检查代码是否遵循分层架构、错误处理规范、安全策略等 Rules 约束。
L4 架构 → 不破坏现有设计（人工+AI 联合审查） — AI 负责分析变更影响范围，人工负责判断架构层面的合理性。
核心理念： 四层评估层层递进，从"能编译"到"逻辑对"到"符合规范"到"不破坏架构"。任何一层不通过都不能合入。
支柱六：约束与恢复（3 级）
核心问题：怎么防止 AI 越界操作？出错了怎么快速恢复？
Harness 通过三级约束体系控制 AI 的行为边界，同时提供可靠的恢复机制：
硬性红线（Rules）→ 不可违反 — 最高优先级约束，定义"绝对不能做的事"——禁止删除生产数据库、禁止修改核心认证逻辑等。违反时 AI 必须拒绝执行并说明原因。
软性约束（Skills）→ 推荐遵循 — 封装在 Skills 中的代码风格偏好、错误处理最佳实践、API 设计约定等。不强制，但凝结了团队经验和共识，价值在于"一致性"。
安全策略（Safety）→ 兜底保护 — 系统级安全网——限制操作目录、禁止危险命令、敏感操作要求人工确认。由工具本身提供，无需手动配置。
恢复机制 → Git 回滚、编译失败自动回退 — 所有 AI 变更通过 Git 管理，可随时回滚到稳定版本。编译或测试失败时自动回退到变更前状态。核心思想：允许犯错，但不允许犯不可逆的错。
设计原则： 三级约束 + 恢复机制 = "有边界、有兜底、有退路"。AI 在约束范围内自由发挥，出了边界自动拦截，犯了错误可以回滚。
6 大支柱与工具链映射总表
| 支柱 |
核心问题 |
对应工具 |
团队实践 |
| 上下文管理 |
AI 看到什么信息？ |
Spec 文档 / AGENTS.md / 知识库 |
结构化规范 + 渐进式披露 + 业务知识挂载 |
| 工具系统 |
AI 能触达什么？ |
MCP / Skills / 知识库 |
DB/API 实时接入 + Skills 专家经验 + 知识库业务沉淀 |
| 执行编排 |
AI 按什么顺序做？ |
Plan 模式 / SDD / 多 Agent |
P1 计划→P2 编码→P3 交付→P4 沉淀 |
| 状态与记忆 |
AI 记住什么？ |
Git + Memories + Spec Deltas |
长期记忆持久化，变更可追溯 |
| 评估与观测 |
AI 做得对不对？ |
自动测试 + AI CR |
编译→测试→审查四层闭环 |
| 约束与恢复 |
AI 不能做什么？ |
Rules + Safety 策略 |
硬性红线 + 自动回滚 |
AI Coding 一体化架构
基于 Harness 6 个支柱，落地成一套完整的架构蓝图——从"人的想法"到"能跑的代码"的全链路：
- 输入层 — Spec 文档 / 自然语言 / 代码上下文
- 配置中心 — Rules / Skills / Docs / Commands / Memories
- 模式引擎 — Plan 模式 / Agent 模式
- Agent 核心 — 代码生成 / 审查 / 测试 / 重构
- MCP 层 — DB / API / Wiki / CI/CD / Monitor
- 输出层 — 代码 / 测试 / 文档 / 日志
- 度量层 — AI 代码占比 / 交付量 / Bug 率
第二部分：落地实操
分阶段实施路线图、具体配置步骤、反模式与合规自检
实施路线图（3 阶段渐进式）
落地不是一蹴而就的事。整个过程拆成三个阶段，每个阶段有明确的目标和验收标准：
01 基础建设（1-2 周） — team-harness 仓库搭建、Rules + AGENTS.md、知识库配置。
02 工具接入（2-4 周） — MCP 接入、Skills 沉淀、Plan 模式 SDD 跑通。
03 持续优化（持续） — 度量看板、规范迭代机制、知识飞轮。
核心原则：每个阶段有明确的目标和验收标准，不急于求成。
创建 team-harness 仓库
这是团队规范的 唯一真实来源，所有 Rules、Skills 模板集中管理。
标准目录结构：
team-harness/
├── rules/ # 团队 Rules 集合
│ ├── global/ # 全局通用规则
│ │ └── base.md # 基础规范（所有项目必须加载）
│ ├── golang/ # Go 语言专用规则
│ │ └── go-backend.md
│ ├── python/ # Python 专用规则
│ └── frontend/ # 前端专用规则
├── skills/ # 团队 Skills 集合
│ ├── common/ # 通用 Skills
│ │ ├── skill-creator/ # Skill 创建器
│ │ └── find-skills/ # Skill 搜索器
│ └── business/ # 业务 Skills
├── templates/ # 模板文件
│ ├── AGENTS.md # AI 说明书模板
│ └── project.md # 项目描述模板
├── docs/ # 使用文档
│ └── onboarding.md # 新人上手指南
└── README.md
同步机制： 业务项目通过脚本或 CI 自动拉取最新规范。
Rules 配置体系
Rules 是 AI 每次交互必须加载的全局约束 —— AI 的"法律"。
👤 User Rules — 作用域：所有项目（个人）。配置方式：IDE 设置页面 → Rules。加载方式：每次对话自动带入。示例：中文回复、camelCase 命名、优先标准库。
👥 Team Rules — 作用域：团队所有成员。配置方式：Knot 平台管理下发。加载方式：按 type 配置（always / manual）。示例：分层架构、Swagger 注解、安全策略。
📁 Project Rules — 作用域：单个项目。配置方式：.rules/ 目录下的 .md 文件。加载方式：总是生效 或 手动 @ 引用。示例：错误处理规范、数据库操作约束。
Rules 文件必须包含 Frontmatter： type: always 或 type: manual
Rules 文件编写规范
---
description: "Go 后端开发通用规范"
globs: "**/*.go"
alwaysApply: true
---
## 一、架构约束
1. 分层架构：Controller → Service → Repository → Model
2. 禁止在 Controller 层编写业务逻辑
3. 数据库操作必须通过 Repository 层
4. 所有对外 API 必须包含 Swagger 注解
## 二、代码风格
1. 函数必须有简要注释
2. 错误处理禁止用 _ 忽略
3. 变量 camelCase，常量 ALL_CAPS
4. 单个函数不超过 80 行
## 三、安全策略
1. 数据库变更优先生成 SQL 脚本
2. 敏感配置通过配置中心读取，禁止硬编码
AGENTS.md 编写指南
AGENTS.md 是 AI 的"说明书"，控制在 ~100 行以内，当 目录索引 用，指向更细分的文档。
# AI 开发助手说明书
## 项目概述
本项目是 [项目名称]，基于 Go 微服务架构。
## 架构说明
- 分层架构：Controller → Service → Repository → Model
- 详细文档：参见 `docs/ARCHITECTURE.md`
## 目录结构
- `internal/` - 业务逻辑
- `pkg/` - 公共工具库
- `api/` - API 定义
- `configs/` - 配置文件
## 开发规范
- 代码规范：参见 `.rules/go-backend.md`
- 数据库规范：所有查询走 Repository 层
核心原则： AGENTS.md 是目录索引，不是百科全书。保持精简，让 AI 按需深入。
知识库配置详解
知识库是让 AI 从"通用模型"变成"懂业务的助手"的核心手段。
| 类型 |
数据来源 |
适用场景 |
| iWiki 文档库 |
团队 Wiki 空间 |
业务文档、技术方案、API 说明 |
| 代码库 |
Git 仓库代码 |
公共组件 SDK、框架源码 |
| 自定义文件 |
Markdown / PDF / txt |
需求文档、设计稿、会议纪要 |
| AI Wiki |
基于代码库自动生成 |
项目架构理解、模块逻辑梳理 |
推荐清单：
| 优先级 |
推荐知识库 |
类型 |
| P0 |
团队技术文档 / 核心公共库 |
iWiki |
| P1 |
业务需求文档 / 项目 AI Wiki |
自定义 / AI Wiki |
| P2 |
运维手册 |
iWiki |
第二阶段：MCP 配置详解
MCP 是 AI 的"感知触手"，突破代码仓库边界。
配置示例（mcp.json）：
{
"mcpServers": {
"db-mysql": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-server-mysql"],
"env": { "MYSQL_HOST": "127.0.0.1" },
"transportType": "stdio"
}
}
}
简单脚本/纯逻辑推理场景直接调 API，不需要 MCP。
团队 MCP 接入清单：
| 优先级 |
MCP Server |
接入目的 |
验收标准 |
| P0 |
DB MCP |
AI 实时读取数据库 Schema |
AI 能准确描述任意表结构 |
| P0 |
工蜂 MCP |
读取代码仓库、Issue、MR |
AI 能读取 Issue 并给出实现思路 |
| P1 |
iWiki MCP |
挂载团队 Wiki 文档 |
AI 能回答业务领域问题 |
| P1 |
TAPD MCP |
读取需求和任务 |
AI 能读取需求并生成 Spec |
| P2 |
CI/CD MCP |
触发构建和查看日志 |
AI 能执行构建并分析失败原因 |
Skills 配置详解
Skills 是给 AI 的 操作手册 —— 把团队的专家经验、最佳实践和操作流程固化成 AI 可执行的指令。
---
name: "rainbow-config"
description: "配置中心的连接、查询和更新操作"
---
## 前置条件
- 项目已引入 `pkg/rainbow` 包
## 操作步骤
1. 初始化连接配置中心
2. 查询分组配置（KV 型或 Table 型）
创建流程： 安装 skill-creator → AI 分析创建 → 审查 → 验证 → 上传仓库。
核心原则：一个 Skill 只解决一类问题
任务双模式：Goal 驱动 vs Spec 驱动
两种任务执行模式，应对不同开发场景。
🎯 Goal 驱动 — 定位：描述期望终态，Agent 自主规划路径、持续迭代。输入：自然语言描述最终目标（如"覆盖率提升到 80%"）。执行：自驱循环，每轮评估进度，未达成自动继续。场景：测试覆盖率提升、代码重构、性能调优。
📋 Spec 驱动 — 定位：先对齐需求生成结构化 Spec，审核后逐项执行。输入：任务描述 → 需求澄清 → 结构化 Spec。执行：按 Spec 任务清单顺序执行，支持中途追加。场景：新功能开发、按设计稿实现、明确需求交付。
| 维度 |
Goal 驱动 |
Spec 驱动 |
| 导向 |
目标导向，Agent 自主规划 |
规划导向，按既定方案执行 |
| 输入 |
期望终态 |
结构化方案（需求/设计/任务/验收） |
| 执行 |
自驱迭代，自行判断完成度 |
按清单顺序执行 |
| 可控性 |
过程灵活，可暂停编辑目标 |
需求明确，可追溯可审查 |
使用建议： 目标明确但路径不清 → 用 Goal；需求复杂需对齐 → 用 Spec。两者也可结合：生成 Spec 后开启"目标"开关，以 Goal 模式自动迭代执行。
团队协作红线与反模式
🚫 四条红线
- 先 Spec 后 Code — 无明确 Spec 禁止直接 Coding
- Rules 共享 — 项目级 Rules 必须同步至 Git
- Skill 沉淀 — 通用逻辑抽象为 Skill 全队复用
- MCP 优先 — 关键元数据通过 MCP 实时同步
⚠️ 变更可追溯
格式：type: [scope] description，type：feat / fix / docs / style / refactor / test / chore。示例：feat: [user] 新增用户操作日志模块
常见反模式：
| 反模式 |
正确做法 |
| 巨型 Prompt |
先 Plan 生成 requirements.md，拆解执行 |
| 跳过审核直接编码 |
半天以上需求必须走 Spec 驱动 |
| Rules 写了不维护 |
月度 Review 定期检查更新 |
| MCP 过度接入 |
只接入 P0/P1 优先级的 MCP |
| Skill 不原子化 |
一个 Skill 只解决一类问题 |
| 盲目信任 AI 输出 |
所有 AI 代码必须人工 Code Review |
| Chat 历史当文档 |
需求持久化到 .rules/plan/ |
| 一个 PR 改所有 |
一个 PR 只解决一个问题 |
合规性自检：better-harness
开源 AI 编程工作流工程化分析工具，通过采集任务执行、项目配置与 Agent 行为证据，评估 AI 编码的规范性、可控性与交付质量。
三大证据域：
| 证据域 |
采集范围 |
| Session Evidence |
目标理解、步骤规划、工具调用、代码变更、验证行为 |
| Project Harness |
构建脚本、测试框架、CI 配置、lint 规则 |
| Agent Customize |
Rules、Skills、MCP、Memory、Hooks |
五维工作环：
| 维度 |
核心检查 |
典型问题 |
| Task Understanding |
目标清晰、Done 标准明确 |
Agent 解错题、理解偏差 |
| Controlled Execution |
有 Plan/Goal 约束、步骤可复现 |
执行不可控、无规划 |
| Change Validation |
变更后实际运行测试/lint |
"看起来没问题"但没验证 |
| Reliable Delivery |
PR 规范、CI 通过、有回滚方案 |
PR 合了下游崩了 |
| Learning Capture |
经验沉淀为 Rule/Skill/Memory |
同一个坑反复踩 |
第三部分：三大工具 × 六大支柱落地对比
QoderCN IDE · ZCode · DeepSeek Harness — 同一规范体系，不同工具实现
三大工具定位与开源方案选型
🟢 QoderCN IDE — 定位：桌面应用（原通义灵码）。特点：开箱即用，内置完整 Harness 能力。亮点：Better Harness 五维度评估 + Quest 2.0 任务编排 + RepoWiki 工程知识库。→ 六大支柱 全覆盖
🟣 ZCode — 定位：智谱 Agentic Development Environment。特点：围绕 GLM-5.3 深度联调的 ADE。亮点：Goal 模式自主推进 + Wiki 仓库知识 + 飞书/微信 Bot 远程协作。→ 六大支柱 基本覆盖
🟡 DeepSeek Harness — 定位：通用 Agent 工具（如 Cursor、Cline 等）。特点：需外部开源框架补充工程化能力。亮点：灵活组合开源方案，按需搭建 Harness 体系。→ 需 统一开源方案 补齐
核心原则： 工具可换，规范不变。团队的 Rules、Skills、MCP 配置才是核心资产。
DeepSeek Harness 统一开源方案选型：
| 开源方案 |
用途 |
对应支柱 |
| Open-Spec |
规范驱动 + 上下文管理 |
上下文管理 |
| Superpowers |
工具扩展 + 多 Agent 编排 |
工具系统 + 执行编排 |
| Aider |
Plan/Goal 驱动任务执行（Architect 模式） |
执行编排 |
| Mem0 |
跨会话记忆管理 |
状态与记忆 |
| Git + Pre-commit Hooks |
版本控制 + 约束恢复 |
状态记忆 + 约束恢复 |
Aider Architect 模式详解
Aider 是专为编程场景设计的开源 Agent 工具，其 Architect 模式 完美实现 Plan/Goal 驱动的任务执行：
# 启动 Architect 模式（Plan → Confirm → Execute）
aider --architect --model deepseek-chat
# 或使用 edit-format 控制执行粒度
aider --edit-format diff
工作流程：
- Plan 阶段：用户描述需求，Aider 进入 Architect 模式，由模型输出详细变更方案
- 确认阶段：人工审阅变更方案，确认无误后同意执行
- Goal 阶段：Aider 按确认的方案执行代码修改，自动处理多文件变更
- 验证阶段：每步执行后可编译/测试验证，失败可回退重新生成方案
如果团队同时使用多个模型（GLM、DeepSeek、Claude 等），模型 API 的切换与适配也会消耗不少精力。借助 RouteFast.ai 这样的统一 API 中转服务，可以降低多模型接入和密钥管理的成本。
适用场景： 适合使用通用 Agent 工具（Opencode、DeepSeek Harness 等）的团队，通过 Aider 补齐 Plan/Goal 驱动的执行编排能力。
六大支柱对比一览
支柱一：上下文管理
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| 规则配置 |
✅ Rules 三层体系 |
✅ Command 自定义指令 |
✅ Open-Spec 规范文件 |
| 代码库索引 |
✅ Codebase Indexing |
✅ 任务与文件管理 + Git |
✅ Git + AGENTS.md |
| 知识库 |
✅ RepoWiki + 企业知识库 |
✅ Wiki 自动生成 |
✅ Git docs/ 目录 |
| 渐进式披露 |
✅ Rules 按 globs 加载 |
✅ Memory 按需带入 |
✅ Open-Spec 分层加载 |
支柱二：工具系统
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| MCP 协议 |
✅ 内置 MCP 支持 |
✅ MCP 服务管理 |
✅ MCP 协议接入 |
| Skills 技能 |
✅ Skills + 技能市场 |
✅ Skill 系统 |
✅ Superpowers 框架 |
| 浏览器自动化 |
✅ Browser Agent |
✅ 浏览器自动化 |
✅ Playwright MCP |
| 自定义智能体 |
✅ 专家团协作 |
✅ 子智能体 |
✅ Superpowers 多 Agent |
支柱三：执行编排
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| 任务规划 |
✅ Quest 2.0 / Plan / Goal |
✅ Goal 模式 |
✅ Open-Spec SDD |
| 多步执行 |
✅ Quest 流水线 + 快照回滚 |
✅ Agent 自动校验 |
✅ Aider Architect |
| 模式切换 |
✅ 多模式切换 |
✅ 提问/Goal/自动化 |
✅ Plan → Agent |
支柱四：状态与记忆
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| 跨会话记忆 |
✅ Memory 记忆感知 |
✅ Memory 项目级 |
✅ Mem0 外部记忆 |
| 自动学习 |
✅ 对话中自主形成 |
✅ 从对话提炼偏好 |
✅ Mem0 自动提取 |
| 变更追溯 |
✅ 快照回滚 + Git |
✅ 编辑历史 + Git |
✅ Git 版本控制 |
支柱五：评估与观测
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| Harness 评估 |
✅ Better Harness 五维度 |
⚠️ 无内置评估 |
✅ Git Diff + lint |
| 代码审查 |
✅ Code Review Agent |
⚠️ 人工审核 |
✅ 开源 CR 框架 |
| 安全检测 |
✅ 代码安全检测 |
✅ 安全操作确认 |
✅ Pre-commit Hooks |
支柱六：约束与恢复
| 能力维度 |
QoderCN IDE |
ZCode |
DeepSeek Harness |
| 硬性约束 |
✅ Rules 不可违反 |
✅ Hooks 自动执行 |
✅ Rules 文件 |
| 自动修复 |
✅ Better Harness 一键修复 |
✅ 编辑历史对话 |
✅ Git 回滚 |
| 恢复机制 |
✅ 快照回滚 |
✅ 编辑历史 + Git |
✅ Git 版本控制回滚 |
关键要点
🟢 QoderCN IDE — 全面覆盖 — 六大支柱全覆盖，开箱即用。Better Harness 是独有的自我评估和修复能力。Quest 2.0 + RepoWiki + Subagent 构成端到端任务交付。
🟣 ZCode — GLM 生态深度优化 — Goal 模式让 Agent 自主推进长程任务。Wiki 自动生成架构导读 + Mermaid 图表。飞书/微信 Bot + Remote 手机端实现多端协作。
🟡 DeepSeek Harness — 灵活开源组合 — 统一使用 Open-Spec + Superpowers + Mem0 等开源方案。灵活度高，可按需选择和替换各模块。需要团队自行搭建和维护 Harness 体系。
💡 核心结论 — 工具可换，规范不变。无论使用哪种工具，团队的 Rules、Skills、MCP 配置、AGENTS.md 等 Harness 资产保持一致。建议优先使用 QoderCN / ZCode 的原生能力，减少外部依赖。
第四部分：总结
从"人驱动 AI"到"AI 自驱动"的工程化转变
核心要点回顾
🎯 核心理念 — Agent = Model + Harness。模型提供智能，Harness 让智能变成生产力。6 大支柱构成完整的约束体系。Harness 不是束缚，是团队的共同语言和质量底线。
🔧 落地路径 — 3 阶段渐进式：基础建设 → 工具接入 → 持续优化。核心工具：Rules + Skills + MCP + Plan 模式。质量闭环：编译 → 测试 → 审查 → 归档。
👥 团队协作 — 先 Spec 后 Code，变更可追溯。3+1 Phase 标准化工作流。多 Agent 角色：Planner → Generator → Evaluator → Archiver。
🔄 知识飞轮 — 新成员越多，整体效率反而越高。经验沉淀 → 规范迭代 → 工具优化。度量层反馈推动配置层持续改进。
让各类工具适配规范，而不是靠个人去适配各类工具。这就是从"人驱动 AI"到"AI 自驱动"的转变。
流水的工具，铁打的规范。
发表于 前天 01:03
|
查看: 0|
回复: 0
