Model+Harness=Agent是由DeepSeek提出的AI开发公式 

在公式中，Model（模型）作为Agent的底座，负责理解、推理和生成。Harness被定义为除模型本身以外的所有工作，是连接模型与真实工作流的关键，其能力涵盖上下文管理、工具调用、任务规划、文件读写、代码修改、终端执行、反馈回收与评测闭环等。Agent则由Model与Harness结合而成，是能够进入并处理实际工作流的智能体 [1]。

该公式旨在将模型能力应用于Agent产品开

一、先理解Harness是什么

在 AI 编程语境里，你可以把 Harness 理解成一套规范好的"智能体脚手架"：它不是单个 Prompt，也不只是某个插件，而是一套围绕 AI 助手构建的工程化运行环境与规则系统。

它会把需求、上下文、技能、验证、记忆、并行协作这些原本散落在聊天中的东西，沉淀成可复用的结构。

Harness 的价值并不是"让 AI 更会聊天"，而是让 AI 在复杂工程里变得更可控、更可验证、更可规模化。

二、6 个代表性框架一览

这 6 个框架并不是同一种东西，而是 Harness 不同层级上的能力模块：

框架	定位层	核心关注点	适合场景
OpenSpec	规范层	SDD（规格驱动开发），先对齐再动手	需求经常漂移、AI 老跑偏
Superpowers	技能/行为约束层	把 TDD、调试、review、worktree 做成 agent 默认动作	AI 写代码太随意、缺工程纪律
GSD	上下文工程 + 阶段化执行层	解决 context rot，阶段化推进	长任务容易崩、大仓库重构
OMC	多代理编排层	team-first orchestration，tmux workers + tri-model advisor	Claude Code 重度用户、并行场景
ECC	性能增强与能力补全层	skills / instincts / memory / 安全扫描 / 持续学习	工程经验难沉淀、跨平台统一
Trellis	结构/任务/项目记忆层	.trellis/spec/ + tasks/ + workspace/，跨平台记忆	多工具团队、长期协作项目

如果用一句话概括它们的分工：

• OpenSpec 负责：先把"要做什么"说清楚
• Superpowers 负责：让 agent 默认按工程纪律工作
• GSD 负责：把复杂任务拆进干净上下文中执行
• OMC 负责：把 Claude Code 组织成团队式执行系统
• ECC 负责：给 Harness 补技能、记忆、安全、验证和学习能力
• Trellis 负责：把 specs、tasks、workspace 变成统一工作流骨架

三、Trellis 详解：长期工作流骨架

核心定位

Trellis 是 Harness 工程化框架中的结构层、任务层和项目记忆层。它的核心目标是用 .trellis/ 这套结构，把项目规范、任务上下文和工作连续性统一起来。

与其他框架不同，Trellis 不是围绕某一次聊天运行，而是让项目围绕结构化的 specs / tasks / workspace 运行。

核心目录结构

.trellis/
├── spec/          # 项目规范（自动注入）
├── tasks/         # 任务驱动工作流
└── workspace/     # 项目记忆与工作连续性

目录	功能	解决的问题
.trellis/spec/	自动注入 Spec	需求只存在于聊天里，输出不稳定
.trellis/tasks/	任务驱动工作流	任务上下文难以沉淀
.trellis/workspace/	项目记忆	跨会话"失忆"问题

六大核心功能

功能	说明
自动注入 Spec	项目规范自动加载到 AI 上下文
任务驱动工作流	以任务为中心组织工作，而非以聊天为中心
并行 Agent 执行	支持多 Agent 并行协作
项目记忆	workspace journals 和 task context 沉淀项目知识
团队共享标准	统一团队工作流标准
多平台复用	不把能力绑定在单一平台

适用场景

"如果你的问题不是'某个 agent 不够强'，而是'团队 workflow 没有统一骨架'，那 Trellis 的价值会非常高。"

• 多工具团队协作
• 长期项目需要记忆沉淀
• 需要跨平台统一工作流标准

四、claude-mem 详解：跨会话记忆外挂

核心定位

claude-mem（54-61K star）是 Claude Code 的跨会话持久化记忆插件，解决每次新会话"从零开始"的问题。

核心功能

功能	说明
自动记忆	记录工具使用 / 代码改动 / 语义摘要
搜索历史	跨会话检索相关上下文
隐私控制	<private> 标签保护敏感信息
Web UI	localhost:37777 管理界面

技术架构

• 5 个 Lifecycle Hooks（自动记录和索引）
• SQLite 本地存储 + Chroma 向量数据库
• MCP 协议 + 支持 OpenClaw Gateway
• 三层检索过滤，号称省 10 倍 Token 成本

安装：npx claude-mem install

五、Trellis vs claude-mem：区别与联系

核心对比

维度	Trellis	claude-mem
本质	Harness 框架（结构层）	Claude Code 插件（记忆增强层）
层级	项目/团队级工作流骨架	个人/会话级记忆扩展
核心目标	统一团队工作流标准，跨平台结构化沉淀	解决 Claude Code 跨会话"失忆"问题
绑定平台	多平台通用	主要服务 Claude Code
Spec 管理	✅	❌
任务管理	✅	❌
语义搜索	❌	✅
团队共享	✅	❌

一句话总结

Trellis 是"团队的工作流骨架"，claude-mem 是"个人的记忆外挂"。
Trellis 让项目有结构，claude-mem 让记忆可搜索。两者可以互补，但 Trellis 本身已经包含基础的项目记忆能力。

六、为什么重型框架建议单独使用？

多个框架同时使用容易出现四个问题：

问题	具体表现
规范重复	多个框架各自定义规则，互相打架
任务资产重叠	各框架都有自己的任务/状态管理，数据分散
状态记录分散	事实来源不一致，AI 不知道听谁的
控制面膨胀	协调成本超过执行产出

如果没有明确主次关系，2个以上框架一起上，就很容易出现：规范重复、任务资产重叠、状态记录分散、事实来源不一致。 最后把系统本身搞得比业务还复杂。

采用策略

轻型框架可以双层叠加（各补不同层，互不干扰）：

• OpenSpec + Superpowers：先解决"别跑偏"，再解决"别乱写"
• OpenSpec + GSD：前者固定规格，后者解决 context rot
• OMC + Superpowers：前者负责编排，后者补工程纪律

重型框架建议单独使用（各自已经是体系型方案）：

• 选 Trellis → 就用它统一 specs/tasks/workspace
• 选 ECC → 就用它统一 skills/memory/security/verification
• 选 OMC → 就用它统一 team-first orchestration

七、最佳组合推荐

默认最佳：OpenSpec + Superpowers

对绝大多数开发者来说，最痛的两层是：

痛点	对应框架	为什么最痛
需求跑偏，AI 猜你要什么	OpenSpec（规范层）	需求不清是所有问题的根源
AI 写代码太随意，缺工程纪律	Superpowers（技能层）	能跑 ≠ 写得好

两者恰好覆盖两个不同层级，互不重叠，可以安全叠加。

与其他组合的对比

组合	覆盖层	优势	劣势	适合谁
OpenSpec + Superpowers ✅	规范层 + 技能层	最轻、最基础、学习成本最低	不解决 context rot 和多 Agent	大多数个人/小团队
OpenSpec + GSD	规范层 + 执行层	规格清晰 + 长任务稳定	两个都偏流程管控，容易太重	长任务多、大仓库重构
OMC + Superpowers	编排层 + 技能层	多 Agent 并行 + 工程纪律	OMC 绑定 Claude Code，偏重	CC 重度用户、明确需要并行
单独 Trellis	结构层	多平台、统一骨架	单次爽感不强，偏长期沉淀	多工具团队
单独 ECC	增强层	覆盖面最广	太重，初学者不友好	进阶用户

推荐的进阶路径

第一步（起步）：OpenSpec
    ↓ 运行稳定，发现 AI 写代码太随意
第二步（补纪律）：+ Superpowers
    ↓ 长任务变多，出现 context rot
第三步（补执行）：考虑换成 OpenSpec + GSD
    ↓ 需要多 Agent 并行
第四步（换编排）：考虑换成 OMC（单独使用）

先轻后重，先补最痛的层，确认跑稳了再考虑下一层。

八、跨平台场景（Claude Code + Trae）的调整方案

如果你同时使用 Claude Code 和 Trae，且以 Solo 开发为主、工程不大，需要对默认方案做调整。

约束条件分析

约束	对选型的影响
Claude Code + Trae 双平台	排除 OMC（绑定 Claude Code），需要平台无关方案
Solo 开发者	不需要多 Agent 编排
跨平台	需要两边的 AI 都能读到同样的规范和记忆
工程不大	不需要重型框架，轻量优先

调整后的推荐：OpenSpec + 规范文件

你的项目/
├── CLAUDE.md              # Claude Code 专用规则
├── .trae/rules.md         # Trae 专用规则
├── specs/                 # OpenSpec：需求/设计/任务（两平台共享）
│   ├── proposal.md
│   ├── design.md
│   └── tasks.md
└── docs/                  # 项目文档（两平台共享）
    ├── product_spec.md
    ├── plan.md
    └── conventions.md     # 工程规范：TDD纪律、代码风格等

核心思路：

层	做法	为什么
规范层	OpenSpec 的 specs/ 目录	两平台共享，AI 不管用哪个工具都先读 spec
行为约束层	把 Superpowers 的原则写进 docs/conventions.md	不依赖斜杠命令，靠规范文件约束
记忆层	docs/plan.md 记录进度	两平台共享，切换工具时不会断档

OpenSpec 仍然适用，因为它是纯 Markdown 文件框架，不依赖任何特定平台。

Superpowers 的斜杠命令在 Trae 上用不了，但其背后的工程方法论（TDD、review、worktree）是通用的，可以写进共享文档让两个平台的 AI 都遵守。

不需要引入完整 Trellis——工程不大时，用 OpenSpec 的 specs/ 替代 .trellis/spec/，用 docs/plan.md 替代 .trellis/workspace/，取其思想但不引入完整框架。

九、总结

场景	推荐组合
大多数个人/小团队起步	OpenSpec + Superpowers
长任务多、大仓库重构	OpenSpec + GSD
Claude Code 重度用户、需要并行	OMC（单独）
多工具团队、长期协作	Trellis（单独）
Claude Code + Trae 跨平台 Solo	OpenSpec + 规范文件（轻量版）

《AI全栈编程案例实操: 从Vibe Coding到Spec Coding和从MCP到Skills Claude code综合编程案例实操》

课程背景

当前AI编程的核心挑战在于：开发者虽然能借助工具快速生成代码片段，却面临着“局部高效、全局混乱”的困境——Vibe Coding带来的意图模糊、架构不一致、团队协作困难等问题日益凸显，而Spec Coding的转换门槛又让许多项目陷入“知其然不知其所以然”的僵局。与此同时，MCP、Skills等新兴架构的快速迭代造成了技术选型碎片化，让团队在“效率与质量”“创新与稳定”之间难以平衡。

本课程正是为了解决这些痛点而生。我们提供从Vibe到Spec的渐进式转型路径，建立融合MCP与Skills的工程化架构，并贯穿从产品设计到软件测试的全栈实践。通过企业系统等真实案例，您将掌握如何让AI编程不再是零散的点状工具，而是成为系统化、可协作、可持续的全流程生产力引擎，真正实现“人机协同”的下一代软件开发范式。案例

课程特色

• 双轨并进：Vibe Coding与Spec Coding对比教学
• 架构演进：MCP基础到Skills综合应用
• 全流程覆盖：产品设计→开发→测试→部署
• 案例驱动：完整企业项目贯穿始终

学员收获

• 掌握AI编程两种核心范式转换能力
• 具备MCP和Skills架构设计实施能力
• 熟悉AI全栈工程化全流程实践
• 完成可展示的完整商业项目案例
• 建立AI时代软件开发的系统性思维框架

课程大纲

第一天 主题：AI编程速成与MCP工具实战

第一部分：AI编程基础认知

1.1 AI编程环境搭建
1.1.1 安装配置Qoder国内环境
1.1.2 安装配置Claude Code开发环境
1.1.3 安装配置OpenCode备用环境

1.2 工具链验证
1.2.1 测试各工具API连通性
1.2.2 配置本地代码运行环境
1.2.3 验证代码生成与执行流程

1.3 五分钟快速实战
1.3.1 现场演示：用Claude生成信息登记表
1.3.2 现场演示：用Qoder生成同款页面
1.3.3 对比分析不同工具生成效果

第二部分：数据处理实战

2.1 需求描述方法论
2.1.1 三个核心要素：做什么、有什么数据、要什么结果
2.1.2 五个实用提问模板：模板1到模板5
2.1.3 每人现场演练：描述一个真实工作需求

2.2 月度数据统计表实战
2.2.1 场景设定：各部门办件数量统计
2.2.2 AI生成代码：从需求描述到Python脚本
2.2.3 运行验证：处理Excel数据生成统计图表

2.3 批量Word文档处理实战
2.3.1 场景设定：100个Word文件关键信息提取
2.3.2 AI生成批量处理程序：python-docx实现
2.3.3 现场实操：处理自备Word文件并输出汇总表

2.4 案例实操：UI真人案例测试

2.5 Spec RAG(存量文档转为)知识库构建查询

2.6 技术存量代码的重构和优化（）

第三部分：Rules与Skills实战

3.1 Rules规则配置
3.1.1 创建代码注释规则：强制添加函数说明
3.1.2 创建文件命名规则：按日期时间自动命名
3.1.3 创建错误处理规则：明确错误提示信息

3.2 Skills技能封装
3.2.1 数据报表Skill：封装统计报表生成模板
3.2.2 表单生成Skill：封装前端表单生成模板
3.2.3 文件批处理Skill：封装文件遍历处理模板

3.2.4  Skills代码的封装

3.3 信息登记表单实战
3.3.1 场景设定：在线收集员工信息
3.3.2 AI生成完整表单：HTML+CSS+JavaScript
3.3.3 数据存储实现：表单提交保存到Excel

第四部分：MCP连接外部工具

4.1 MCP基础配置
4.1.1 安装配置数据库MCP连接器
4.1.2 安装配置文件系统MCP连接器
4.1.3 安装配置Excel MCP连接器

4.2 MCP连接调试
4.2.1 测试数据库MCP：连接MySQL执行查询
4.2.2 测试文件MCP：读写本地文件系统
4.2.3 测试Excel MCP：直接操作Excel文件

4.3 数据库查询分析实战
4.3.1 场景设定：业务数据库统计分析
4.3.2 配置数据库MCP：连接真实业务库
4.3.3 AI直接查询：自然语言问数据出结果

第五部分：Spec Driven开发实操

5.1 Spec规格说明编写
5.1.1 功能规格模板：功能清单与用户故事
5.1.2 数据结构规格：表结构设计文档
5.1.3 接口规格模板：API定义文档

5.2 会议室预约项目介绍
5.2.1 功能需求：查看、预约、记录、取消
5.2.2 技术栈选型：Vue3 + SpringBoot + MySQL
5.2.3 项目结构规划：前后端分离架构

5.3 AI辅助需求分析
5.3.1 用AI生成完整功能清单
5.3.2 用AI生成用户故事和验收标准
5.3.3 现场练习：完善项目需求文档

第六部分：架构设计与Spec编写

6.1 AI辅助架构设计
6.1.1 用AI生成系统架构图设计
6.1.2 用AI进行技术选型分析
6.1.3 用AI评估架构方案可行性

6.2 数据库Spec编写
6.2.1 用AI生成数据库ER图
6.2.2 用AI设计表结构：会议室表、预约表、用户表
6.2.3 现场练习：完善数据库Spec文档

6.3 接口Spec编写
6.3.1 用AI设计RESTful接口列表
6.3.2 用AI定义接口请求响应格式
6.3.3 现场练习：生成完整接口文档

第二天 主题：全流程开发与项目交付

第一部分：数据库与后端并行开发

1.1 数据库生成实战
1.1.1 AI生成建表SQL语句
1.1.2 AI生成测试数据插入脚本
1.1.3 现场练习：创建数据库并导入测试数据

1.2 后端接口生成实战
1.2.1 AI生成Controller层代码
1.2.2 AI生成Service业务逻辑代码
1.2.3 AI生成DAO数据访问代码

1.3 接口测试实战
1.3.1 用Postman测试AI生成的接口
1.3.2 AI辅助调试接口返回问题
1.3.3 现场练习：完成所有接口测试

第二部分：前端开发实战

2.1 前端页面生成
2.1.1 AI生成Vue页面组件代码
2.1.2 AI生成路由配置代码
2.1.3 AI生成API调用服务代码

2.2 页面交互实现
2.2.1 AI生成预约表单验证逻辑
2.2.2 AI生成列表展示与分页功能
2.2.3 AI生成日期选择和时间冲突判断

2.3 前后端联调
2.3.1 配置前端代理解决跨域
2.3.2 联调测试预约完整流程
2.3.3 现场练习：完成所有功能联调

第三部分：功能测试与优化

3.1 测试用例生成
3.1.1 AI生成功能测试用例清单
3.1.2 AI生成边界测试用例
3.1.3 AI生成异常场景测试用例

3.2 手动功能测试
3.2.1 测试会议室查看功能
3.2.2 测试预约提交与取消功能
3.2.3 测试预约记录查询功能

3.3 AI辅助调试
3.3.1 遇到Bug直接问AI解决方案
3.3.2 AI分析错误日志定位问题
3.3.3 现场练习：修复系统存在的Bug

第四部分：代码审查与优化

4.1 AI代码审查
4.1.1 AI检查SQL注入安全风险
4.1.2 AI检查XSS跨站脚本漏洞
4.1.3 AI检查权限控制漏洞

4.2 性能优化审查
4.2.1 AI分析数据库查询性能
4.2.2 AI检查前端渲染性能
4.2.3 AI提出代码优化建议

4.3 代码规范性审查
4.3.1 AI检查Java代码规范
4.3.2 AI检查Vue代码规范
4.3.3 现场练习：按AI建议优化代码

第五部分：压力测试实战

5.1 压力测试脚本生成
5.1.1 AI生成JMeter测试脚本
5.1.2 AI生成并发用户配置
5.1.3 AI生成测试结果分析模板

5.2 压力测试执行
5.2.1 配置50并发用户测试预约接口
5.2.2 监控系统CPU和内存使用
5.2.3 记录响应时间和成功率

5.3 测试结果分析
5.3.1 AI分析测试报告
5.3.2 AI提出系统瓶颈优化建议
5.3.3 现场练习：优化后再次测试对比

第六部分：文档生成与项目交付

6.1 用户手册生成
6.1.1 AI生成操作手册图文教程
6.1.2 AI生成常见问题解答
6.1.3 现场练习：生成个性化用户手册

6.2 技术文档生成
6.2.1 AI生成部署运维文档
6.2.2 AI生成接口文档Swagger格式
6.2.3 AI生成数据库设计文档

Harness 这件事，框架在精不在多；选自己真正需要的，比无脑叠甲重要得多。
核心不是"先把所有东西装满"，而是： 在使用中发现缺口，再把缺口补起来。