文章目录
-
- 一、我想解决什么问题
- 二、几个基础概念
- [三、各 Harness 的定位](#三、各 Harness 的定位)
- [四、Harness 注入信息的五种主要形式](#四、Harness 注入信息的五种主要形式)
- 五、谁最能实现"越用越懂项目"
- [六、实测：两个 Harness 同时跑的情况](#六、实测：两个 Harness 同时跑的情况)
- 七、总结
一、我想解决什么问题
- 让 AI 越用越懂项目（项目背景、代码风格、架构决策）
- 让 AI 越用越理解我的意图（个人偏好、隐性规则）
二、几个基础概念
| 概念 | 说明 | 例子 |
|---|---|---|
| Agent 框架 | 实现 AI 的推理循环（思考→行动→思考） | LangGraph, AutoGen |
| Harness | 套在现成 Agent 外面的控制层，管理输入/输出、工具、记忆 | Trellis, ECC, Superpowers |
| Skill | 一个具体的能力单元 | TDD Skill, Code Review Skill |
类比：Agent 是马，Harness 是缰绳+马鞍，Skill 是具体的动作指令。
Trellis、ECC、Superpowers、OpenSpec、Aegis 都属于 Harness，不是 Agent 框架。
三、各 Harness 的定位
| Harness | 核心定位 | 特点 |
|---|---|---|
| Trellis | 跨 Agent 的统一工作流 | 换底层 AI 工具不改流程，适合团队标准化 |
| Superpowers | 技能注入 | 强制 TDD、代码审查等工程流程 |
| OpenSpec | 规范先行 | 写代码前必须先写规范文档 |
| ECC | 功能最全 | 60+ Subagents、400+ Skills、安全扫描、本能学习系统 |
| Aegis | 深度治理 | 基线优先、证据驱动、防止虚假完成 |
四、Harness 注入信息的五种主要形式
Harness 不修改 Agent 的核心模型，而是在合适的时机把信息"塞进"Agent 的上下文窗口。主要形式如下：
| 形式 | 说明 | 例子 |
|---|---|---|
| 1. 系统提示词注入 | 会话开始时，把项目规范、编码标准等内容拼接到 System Prompt 里 | Trellis 读取 .trellis/spec/ 文件并注入 |
| 2. Skill 注入 | 按需加载一段结构化的提示词+执行逻辑 | ECC 的 400+ Skills，写测试时才加载 TDD Skill |
| 3. 工具/函数注入 | 给 Agent 注册额外的可调用工具（读文件、执行命令等） | Trellis 的 CLI 命令，ECC 的内置工具 |
| 4. 记忆注入 | 从本地数据库或文件读取跨会话的关键信息，自动注入 | ECC 的 SQLite 记忆，Trellis 的 journal.md |
| 5. Hook 注入 | 在 Agent 执行某个动作前后触发脚本，脚本返回值注入上下文 | ECC 的 PreToolUse Hook，可在修改文件前注入警告 |
核心原则：在合适的时机（会话开始、触发 Skill、调用工具、跨会话恢复、Hook 触发），把合适的内容塞进 Agent 的上下文窗口。
五、谁最能实现"越用越懂项目"
ECC 最接近，因为它有 Instincts（本能）系统。
| 能力 | Trellis | ECC |
|---|---|---|
| 静态知识库 | ✅ 需手动更新 | ✅ 非核心 |
| 跨会话记忆恢复 | ⚠️ 半自动 | ✅ 全自动 |
| 自动从对话中学习 | ❌ | ✅ |
| 行为进化（本能→技能） | ❌ | ✅ |
| 质量门禁 | 弱 | ✅ |
但 ECC 主要绑定 Claude Code，团队用多工具时受限。
六、实测：两个 Harness 同时跑的情况
我试过同时装 Trellis 和 ECC，没做集成，日常工作流主要按 Trellis 走。
冲突点
| 方面 | Trellis | ECC | 同时跑的问题 |
|---|---|---|---|
| 任务状态存储 | .trellis/tasks/*.jsonl |
.ecc/state.db |
两处记录，不一致 |
| 会话恢复 | 手动读 journal.md | /save + /resume-session |
两套方式 |
| Hook 机制 | pre_task 等 |
PreToolUse 等 |
可能互相触发 |
| 规则来源 | 静态 spec/*.md | 动态 instincts/ | 冲突时听谁的 |
| 命令行 | trellis task start |
ecc /skills |
认知负担 |
实测结果
- token 用量比只装 Trellis 时高（双份上下文注入）
- ECC 的学习机制（
continuous-learning-v2）在后台自动运行，但它的"本能"触发依赖于特定场景，日常 Trellis 任务流中不容易体现出来 - 实际感受：区别不大，主要还是走的 Trellis
- 后来卸了 ECC，token 降回去了
小结
理论上可以手动写桥接脚本融合冲突，但：
- token 成本实打实上涨
- 对一般项目，感受不到差别（Trellis 本身的 workflow 已经够用）
- 融合投入产出比低
结论：对一般项目，单个 Harness 足够。 选一个用顺手的就行。
七、总结
- Trellis/ECC 等是 Harness（缰绳），不是 Agent 框架。
- Workflow = 团队+AI 的操作手册，Trellis 把它变成了版本可控的文件。
- Harness 通过系统提示词、Skill、工具、记忆、Hook 五种形式向 Agent 注入信息。
- 让 AI 越用越懂项目，关键在于跨会话自动学习 ------ ECC 的 Instincts 最接近。
- 实测：两个 Harness 同时跑，token 涨了但效果没区别。一般项目单个 Harness 足够。
笔记整理自实际折腾过程，供参考。