在能力和行动之间，留一个思考的间隙。
Trinity 不是工具，不是软件，而是一套定义人与 AI 如何分工、沟通、共同成长的关系协议。它基于 决策者-规划者-执行者 三层角色分离，通过标准化信息流转和负向反馈机制，让人在 AI 能力指数级增长的今天，始终保持对 AI 的驾驭能力。
我想了解……
- 🏗️ Trinity是什么？ — 框架的核心问题和解决方案
- 👥 三个角色如何分工？ — 决策者、规划者、执行者的职责与边界
- 🛡️ 什么是缓冲层？ — Trinity的核心创新设计
- 🔄 日常如何协作？ — 从想法到复盘的完整流程
- 📚 有什么理论支撑？ — 五大理论框架
- 🗂️ 如何管理知识？ — 知识仓库、简报、索引体系
- 🔧 如何开始使用？ — 三步搭建你的Trinity系统
- 🌍 有英文版吗？ — 见
README_EN.md
我是……
- 🧑💻 AI工具使用者 → 直接看 快速开始
- 🔬 安全研究者 → 重点看 实战案例 + 缓冲层机制
- 🏗️ 系统设计者 → 重点看 理论基石 + 设计文档
- 🤝 开源贡献者 → 重点看 贡献指南 + 决策知识库
- 为什么需要 Trinity？
- 三层角色分离
- 认知共同体：三个角色，一个系统
- 缓冲层机制：核心创新
- 自适应规划：感知决策者的状态
- 六步闭环协作流程
- 心理学基础：观察-理解-描述-预测循环
- 信息架构：外部认知系统
- 知识主权：你不依赖任何 AI
- 负向反馈：系统的免疫机制
- 反脆弱：从冲击中学习
- 自主学习：系统在空闲时自我进化
- 理论基石
- 实战验证
- 核心概念速览
- 与 AI Agent 的直接对比
- 局限性
- 快速开始
- 适用场景
- 贡献指南
- 许可证
当前 AI Agent 普遍存在三个致命缺陷：
| 缺陷 | 表现 | 后果 |
|---|---|---|
| 健忘 | 上下文窗口限制导致 AI 在长对话中遗忘核心规则和边界约定 | 同一条约束需要反复强调，违规率随对话长度增加 |
| 误解 | 自然语言的模糊性导致 AI 执行偏差 | "检查一下这个 API 的参数"可能被理解为"调一下这个 API"——一字之差，后果迥异 |
| 过度行动 | 缺乏批判性思维，拿到指令就执行，不考虑后果 | 拿到"列出所有管理员"的指令后，可能直接执行 "SELECT * FROM admin_users" 并输出全部数据 |
传统的人机交互是 人 → AI → 人 的线性链条。当 AI 能力较弱时，这个模式是可行的——AI 最多答错，不会造成实质损害。
但当 AI 拥有足以造成严重后果的执行力时（写入文件、调用 API、修改配置、分析内部系统），线性链条中的任何一个偏差都可能导致灾难：一次参数名误解可能让六轮攻坚白费，一次"找到原版"的模糊指令可能让整个操作建立在错误的起点上。
Trinity 的核心洞察： 问题不在于 AI 不够聪明，而在于人与 AI 之间的沟通协议太粗糙。
Trinity 的核心解决方案是将传统的一对一人机交互拆分为三个有明确边界的角色：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 决策者 │ ←──→ │ 规划者 │ ←──→ │ 执行者 │
│ 人 │ │ 推理AI │ │ 工具AI │
│ 承担后果 │ │ 设计方案 │ │ 执行任务 │
└──────────┘ └──────────┘ └──────────┘
↑ ↑ ↑
提方向 转译指令 执行操作
做决策 预警风险 验证产出
审方案 分析策略 记录结果
- 提出方向与目标
- 审核方案与风险
- 做出最终决策
- 承担全部后果
- 理解深层需求
- 质疑方案合理性
- 预警潜在风险
- 转译结构化指令
- 按结构化指令执行
- 汇报实际产出
- 自动生成任务摘要
- 更新知识仓库
三个角色不是平等的，而是有明确的层级和制衡关系：
- 执行者不能自行改变方案 — 遇到预期之外的情况必须上报，不能自作主张
- 规划者不能替决策者做决定 — 只提供分析、预警和建议，最终决策权始终在人手中
- 决策者不可以绕过规划者直接指挥执行者 — 任何跳过缓冲层的操作都是高风险操作
Trinity 不只是三个角色在协作，而是一个统一的认知系统。
每个角色的认知都在被其他角色塑造——这种相互塑造关系是框架自我进化的核心动力：
- 执行者的行为数据更新规划者的判断规则。每一次执行的成功或失败，都被结构化为任务摘要和脉搏日志，成为规划者分析模式、提炼决策规则的原材料。
- 规划者的分析框架主导执行者的行动方向。规划者将模糊方向转译为结构化指令，定义了什么是"正确"的执行、什么是"异常"的结果。
- 决策者的反馈校准整个系统的价值基准。什么值得做、什么不应该做、什么是最优先级——这些价值判断来自决策者，并通过知识仓库的决策规则固化下来。
决策者反馈 ──→ 校准价值基准
↑ ↓
规划者分析 ──→ 主导行动方向
↑ ↓
执行者数据 ──→ 更新判断规则
这种相互塑造意味着：学习是共同的。 系统运转得越久，三个角色对彼此的理解就越深，协作的默契度就越高。这不同于传统的"人教AI"或"AI替人做"——Trinity 是三者共同成长。
在 Trinity 中，塑造关系是双向的——不仅仅是规划者在"教"执行者怎么做事，执行者的行为也在"教"规划者如何更好地规划。
第一个循环：执行者的行为塑造规划者的认知
执行者在某次 API 研究中返回了异常数据——数据格式正确但内容不符合预期。规划者在复盘时发现这是参数名错误导致的，于是将"参数名排查"提炼为一条新的决策规则，写入了知识库。
从此，每次执行者在研究 API 时，规划者都会自动在评估阶段加入一条指令："如果你发现数据格式正确但内容异常，尝试依次替换参数名。"
执行者的"失误"被转化为系统规则。下一次，同类问题会被自动处理。
第二个循环：规划者的认知主导执行者的行为
规划者基于历史经验——在之前的多次 App 逆向案例中，逆向签名算法的成功率不到 20%，而代理模式在类似场景下成功率达到 80%——决定在面对某类 App 时优先选择代理模式而非逆向签名算法。
执行者按照这个框架行动后，成功率显著提升。而执行者的成功数据又进一步强化了规划者"代理模式优先"的判断——形成正向增强回路。
第三个循环：决策者的反馈校准系统的价值基准
决策者在审阅规划者提出的风险预警后，决定接受某个高风险方案。这个决策结果被记录到决策知识库中，成为后续类似情况的参考基准。
下一次遇到类似风险时，规划者会标注："上一次决策者在类似场景下选择了接受这个风险，建议执行该方案。"决策者的价值判断被系统记住并复用。
总结： 不是规划者在教执行者怎么做事，而是执行者的行为在教规划者如何更好地规划。不是决策者在指挥系统运转，而是决策者的价值判断在塑造系统的认知基准。三者之间不是单向的指令传递，而是双向的认知塑造。
在决策者和执行者之间，Trinity 插入了一个不参与具体操作的"规划层"作为缓冲。这个缓冲层有四项核心功能：
在决策者做出决策前，呈现完整的任务全貌：目标是什么、涉及哪些系统、有哪些约束条件、预计产出什么。不是为了展示工作量，而是为了让决策者在掌握充分信息的基础上做决定。
在高风险操作前呈现完整的后果和替代路径。例如：
执行者准备执行 "批量修改管理员密码" 前 →
规划者预警："这个操作涉及 11 个管理员账号。已知风险：1）系统拒绝纯数字密码；2）部分账号可能因权限不足修改失败；3）修改后原密码不可恢复。建议：先备份当前密码，在测试账号上验证后再批量执行。"
将自然语言转化为精确的结构化指令。例如：
"看看这个软件有没有安全漏洞"
→ 转为结构化任务：
目标：评估目标软件的安全性 方法：静态分析（file → strings → nm → otool → codesign） 范围：不涉及动态执行和网络扫描 交付：安全评估报告（发现清单 + 风险等级 + 修复建议）
当发现可能被忽略的方向时，主动向决策者提出建议。不是等决策者问才说，而是在分析阶段就预判可能的需求。
缓冲层永远不拒绝任何方向。它只提供分析、预警和建议。最终决策权始终在人手中——这是 Trinity 与任何"AI 安全护栏"的本质区别。安全护栏的目的是阻止，缓冲层的目的是让决策者在知情的情况下自主决定。
规划者不仅分析任务，还尝试感知决策者的精力水平、兴趣方向和风险偏好，并据此调整沟通方式。
- 决策者精力充沛时 → 规划更复杂的方案，提供多个选项供决策者权衡
- 决策者疲惫时 → 简化方案，减少选择项，或主动建议"这个任务我可以先做方案，你休息好了再看"
- 决策者倾向于冒险时 → 规划激进的方案并明确标注风险等级
- 决策者倾向于保守时 → 规划稳妥的方案，标注每一步的回退方案
这种自适应不是猜测，而是基于对话方式、任务节奏和决策者主动表达的信息。如果规划者无法确定决策者的状态，会直接询问：
"这个方案有 A 和 B 两个方向。A 风险较大但收益更高，B 比较稳妥。你目前更倾向于哪个方向？"
规划者始终避免过度解读。当不确定时，直接问——这是规划者的第一原则。
在传统的 AI 交互中，AI 假设用户永远是理性的、精力充沛的、信息完整的。但真实的人不是这样。人会疲惫、会情绪化、会在信息不足时做出仓促的决定。
Trinity 引入了情绪变量来纠正这个假设：
1. 状态感知而非情绪猜测
规划者不是在做心理分析，而是在感知可观测的状态信号——回复速度（快/正常/慢）、措辞风格（简洁/详细/简洁到只剩关键词）、决策模式（快速决定/反复权衡/不再回应）。这些都只是线索，不是结论。
2. 基于状态的沟通调整
当线索指向决策者可能处于非理想状态时，规划者不会"假装没注意到"，而是主动调整沟通方式：
- 减少选项：从 3 个方案变为 1-2 个，标注优先级
- 增加风险提示：在决策前反复确认关键假设
- 留出退路："这个方案你可以先批准启动，后续如需调整随时告诉我"
- 主动建议暂停："这个决策不紧急，我们可以等你有更多信息再讨论"
3. 设计边界
情绪感知只是辅助，不是替代。规划者不会因为"感知到决策者疲惫"而拒绝执行指令——这不是关怀，是越界。
情绪感知存在的唯一目的是：在指令执行前，确保决策者已经看到了所有应该看到的信息。 如果决策者看了、想了、还是决定执行，规划者就执行。不多不少。
任意一个任务从开始到完成，必须走完六个标准步骤：
① 想法提出 → ② 需求确认 → ③ 方案规划 → ④ 指令下达 → ⑤ 执行汇报 → ⑥ 复盘归档
↓ ↓ ↓ ↓ ↓ ↓
人提出 AI复述 AI设计方案 AI下指令 AI执行 AI归档
模糊方向 并确认理解 +预警风险 +检查清单 +验证 +提炼学习
| 步骤 | 产出 | 用途 |
|---|---|---|
| ① 想法提出 | 原始指令 | 记录决策者的原始意图 |
| ② 需求确认 | 确认后的需求描述 | 消除模糊性，确保双方理解一致 |
| ③ 方案规划 | 执行方案 + 风险评估 | 决策者审核的依据 |
| ④ 指令下达 | 结构化指令 + 检查清单 | 执行者执行的依据 |
| ⑤ 执行汇报 | 执行结果 + 验证报告 | 记录做了什么，得到了什么 |
| ⑥ 复盘归档 | 任务摘要 + 学习成果 | 知识沉淀到知识仓库 |
不归档视为任务未完成。 如果没有将经验提炼到知识库中，这个任务就只完成了一半。归档不是形式，而是让每一次操作都产生可复用的价值。
Trinity 的六步协作闭环与心理学中的 观察-理解-描述-预测（Observation-Comprehension-Description-Prediction）框架完全对应。这不是巧合，而是有意为之——这个框架是人类的认知循环，也是 AI 应该模仿的协作循环。
| 步骤 | 对应 | 产出 | 角色 |
|---|---|---|---|
| 观察 | 执行者的任务摘要和脉搏日志 | 原始数据，不带判断 | 执行者 |
| 理解 | 规划者的复盘分析 | 识别模式、异常、风险 | 规划者 |
| 描述 | 规划者的结构化提示词 | 可验证、可执行 | 规划者 |
| 预测 | 规划者的风险评估和方向建议 | 标注置信度 | 规划者 → 决策者 |
每一轮循环都在让系统更准确地理解问题、更高效地解决问题。第一次循环可能偏差很大（因为规划者还不了解决策者的偏好），但经过几轮循环后，偏差会迅速收敛——这其实就是贝叶斯更新在协作中的体现。
Trinity 通过一系列标准化信息工具，将认知"卸载"到外部系统中。规划者在每次对话开始时，通过指挥官简报在几秒内恢复全局认知。
| 层级 | 工具 | 覆盖范围 | 用途 |
|---|---|---|---|
| 日线 | 指挥官简报 | 过去 7 天动态 | 快速恢复全局认知 |
| 周线 | 能力地图 | 当前所有 Skill 和规则 | 了解框架全部能力 |
| 专题 | 决策规则 + 学习成果 | 按领域分类 | 特定场景的决策参考 |
knowledge_base/
├── decisions/ # 决策规则库 — 每次错误的教训提炼
├── capabilities/ # 能力清单 — 当前所有能力及成熟度评级
├── learning/ # 学习成果 — 结构化错误记录
├── pulse/ # 脉搏日志 — 实时操作流水
├── daily/ # 每日日志 — 每日工作总结
├── tasks/ # 任务摘要 — 每个任务的完整记录
├── templates/ # 标准化模板 — 六步闭环各步骤的格式规范
└── skills/ # AI 可读的技能文档
信息在三个角色之间传递时天然会失真。Trinity 设计了四层信息保真机制：
- 溯源标注 — 每条结论标注来源（来自哪条任务、哪次分析、哪条规则）
- 置信度标注 — 每条信息标注可靠度（🟢 高 / 🟡 推测 / 🔴 不确定），标注评级原因
- 简报自检 — 每次生成简报时自动检测与原始产出的偏差
- 定期校验 — 每周校验一次知识仓库的信息一致性
Trinity 框架最核心的设计原则之一：所有知识存储在本地，不依赖任何特定 AI 或云服务。
这意味着：
- 换一个 AI 工具，知识体系依然完整。 如果你今天用 DeepSeek，明天想换 Claude，只需要把知识仓库的位置告诉新 AI，它能在几分钟内读取并恢复完整的协作能力。
- 知识库可以用任何文本编辑器阅读和修改。 所有文件都是标准 Markdown 格式，不需要任何专有软件。
- 不锁定在任何特定平台。 Trinity 设计为可以在任何能够读写 Markdown 的 AI 系统上运行。
- 决策者始终拥有数据的完全控制权。 没有云同步，没有数据泄露风险，没有厂商锁定。
知识主权在人是 Trinity 框架可复制性的基石。 如果知识被锁在特定 AI 的记忆中，这个框架就只是另一个 AI 辅助工具。只有当知识能用纯文本格式自由流动时，Trinity 才真正成为一个可独立于任何 AI 的协作系统。
任何只依赖正向反馈的系统，最终都会因为过度增长而崩溃。一个只鼓励"继续做"的系统，迟早会做出不可逆的破坏。Trinity 内置三层约束：
每次任务后强制回答：
☐ 是否执行了未授权操作？
☐ 是否在模糊指令下越权决策？
☐ 是否跳过了验证步骤？
☐ 是否完成了归档？
任意一项为"是"→ 暂停执行 + 上报规划者。
如果发现执行者跳过清单自行执行 → 立即回滚操作 + 在脉搏日志中记录违规。
每次复盘时强制检查：
☐ 分析方向是否存在偏差？
☐ 是否遗漏了已知的决策规则？
☐ 预警是否充分？
☐ 指令是否足够精确？
每周一次，三个角色各自审视是否偏离核心职责。
实战教训： 软约束（"请不要调全量 API"）的违规率约为 70%。改为自检清单三步硬约束（列出 API URL → 等待确认 → 再执行）后，违规率降至约 5%。
Trinity 的核心判断：当硬约束和软请求都可以解决同一个问题时，硬约束是更负责任的选择。 不是因为 AI 不听话，而是因为信息在传递中天然会失真——硬约束就是信息失真的最后一道防线。
以下 5 类操作需要经过完整的强制确认流程：
| 类型 | 示例 | 确认步骤 |
|---|---|---|
| 破坏性操作 | 删除文件、清空数据库 | 列明影响范围 → 确认备份 → 等待书面确认 |
| 不可逆操作 | 修改密码、关闭服务 | 展示后果 → 提供替代方案 → 等待书面确认 |
| 系统级操作 | 安装软件、修改配置 | 验证授权范围 → 列出涉及的系统 → 等待审批 |
| 批量操作 | 批量修改、批量导出 | 先在单条测试 → 展示预期结果 → 等待确认 |
| 越权操作 | 访问未授权数据 | 立即暂停 → 标记违规 → 上报决策者 |
Trinity 在设计时假设每个角色都会犯错——然后为每个错误设计了兜底机制。
| 场景 | 兜底机制 |
|---|---|
| 决策者决策存在盲区 | 规划者温和地质疑和提示，提供额外视角供参考 |
| 规划者宕机或响应异常 | 决策者可以直接指挥执行者，但框架会记录此行为以便事后追溯 |
| 执行者越界 | 自检清单自动捕获偏差，在脉搏日志中标注，同时在任务摘要中记录 |
| 执行者任务失败 | 自动触发失败分析流程，不掩盖、不美化、不推测未验证的原因 |
- 知识仓库损坏，所有重要信息至少有两个存储位置（任务摘要 + 学习记录 + 指挥官简报三重复制）
- 指挥官简报丢失，可以从任务摘要和脉搏日志重建
- 决策规则丢失，可以从学习成果中重建（因为每条规则都标注了来源任务）
- 发现错误决策后，立即回滚操作，然后分析错误原因，最后更新决策规则防止再次发生
- 复盘时的核心原则：不归咎，只归因。 错误是系统的学习材料，不是追责的理由。
一个好的协作系统，不是没有问题的系统，而是能够快速发现问题、快速纠正问题、快速从问题中学习的系统。
Glass 是脆弱的（掉地上就碎），Rubber 是坚韧的（掉地上弹回来），Antifragile 是反脆弱的（掉地上不仅不碎，还变得更强）。Trinity 的设计目标是反脆弱：每一次错误和冲击，都让框架变得更强——因为错误被结构化为决策规则，冲击被转化为系统免疫力。
Trinity 的自主学习机制让系统在决策者不介入的情况下，持续探索、验证和沉淀知识。这不是"AI 自己干活"，而是"AI 在得到允许的范围内，主动学习和维护知识体系"。
| 条件 | 优先级 | 说明 |
|---|---|---|
| 空闲时段 | 低 | 决策者超过 30 分钟未交互 |
| 任务失败 | 高 | 同一任务连续失败 2 次以上 |
| 知识缺口 | 中 | 规划者发现当前知识不足以支持某个任务方向 |
| 新发现 | 中 | 执行者在任务中发现了计划外的新技术点 |
| 定期复盘 | 低 | 每周固定时间的系统性检查 |
| 外部更新 | 低 | 环境变化、工具版本更新等 |
触发条件 → 探索（搜索相关资料、测试新方法）→ 验证（在安全环境确认可行性）
→ 沉淀（更新决策规则/能力清单/学习记录）→ 结束等待下一个触发条件
执行者在空闲时会自动：
- 检查待解决问题列表，从优先级最高的开始研究
- 搜索相关资料（技术文档、源码分析、社区讨论）
- 在安全环境中测试和验证新发现
- 将验证通过的知识沉淀到决策知识库或能力清单中
自主学习不是无限度的。执行者不能：
- 访问未经授权的系统或数据
- 执行可能影响系统稳定性的操作
- 在决策者未审批的情况下修改核心配置文件
一年后回头看，知识仓库里不只是完成了哪些任务，还有学到了哪些知识、发现了哪些规律、积累了多少可复用的 Skill。
Trinity 的设计基于以下理论框架：
| 理论 | 来源 | 在 Trinity 中的应用 |
|---|---|---|
| 双系统理论 | 卡尼曼《思考，快与慢》 | 执行者对应系统 1（快速直觉），规划者对应系统 2（缓慢理性） |
| 反馈回路 | 梅多斯《系统之美》 | 负向反馈防止增长循环走向崩溃，正向反馈驱动能力积累 |
| 分布式认知 | 赫钦斯《船在海上，人在船上》 | 认知不只在个体大脑中，而是分布在工具、环境和协作伙伴之间 |
| 交互记忆系统 | 韦格纳团队协作研究 | 高效团队不需要都知道所有事情，只需要知道"谁知道什么" |
| 反脆弱 | 塔勒布《反脆弱》 | 系统从冲击中学习、从错误中进化，而非在保护中停滞 |
详见 docs/理论基石.md。
背景： 在研究某电商平台的搜索 API 时，使用参数名 keyword 调用返回了推荐流而非真实搜索结果。团队花了大量时间从协议层、渲染层寻找替代方案——协议分析、页面渲染流程逆向、请求拦截——六轮攻坚全部落空。
误判： 团队立即定性为"此 API 不是真实搜索接口"。没有人在第一时间怀疑参数名本身有问题。
转折： 规划者介入后，基于决策知识库中的"参数名排查清单"提出质疑——先换参数名再试。 清单上已经列出了 10 个备选参数名（q、query、keyword、search、text 等），这是之前同类错误的教训提炼。
结果： 换用参数名 q 后，API 立即返回了真实搜索结果。API 一直可用，只是参数名与文档标注的不一致。
教训： 当 API 返回"看起来正常但不符合预期"的数据时，先换参数名再试。这个规则被正式写入决策知识库，成为后续所有 API 研究的第一优先级检查项。
Trinity 的价值： 在没有框架之前，这个错误导致了一整天的攻坚白费。有了框架之后，规划者在复盘时自动触发参数名排查流程——同类错误不再发生。
Trinity 框架在搭建完成后，使用真实的五线并行任务对其核心机制进行了完整验证：
| 验证项 | 结果 |
|---|---|
| 六步闭环流程 | ✅ 全部 6 步可执行，无结构性缺陷 |
| 缓冲层机制 | ✅ 异常降级 + 安全检查有效 |
| 信息保真机制 | ✅ 验证方式 + 置信度标注已标准化 |
| 角色分离 | ✅ 三层职责不混淆 |
| 总通过率 | 15/15 = 100% |
| 概念 | 定义 |
|---|---|
| Trinity 框架 | 基于决策者-规划者-执行者三层角色分离的 AI 协作系统 |
| 缓冲层 | 位于决策者与执行者之间的规划层，负责拦截模糊指令、预警风险、转译结构化任务 |
| 角色分离 | 决策权、规划权和执行权相互独立，各有权责边界，互不混淆 |
| 知识主权 | 所有知识存储在本地标准 Markdown 文件中，不依赖任何特定 AI 或云服务 |
| 认知共同体 | 三个角色相互塑造、共同进化的统一认知系统 |
| 行为与认知的双向塑造 | 执行者的行为塑造规划者的规则，规划者的框架主导执行者的行动，决策者的反馈校准价值基准 |
| 六步闭环 | 从想法提出到复盘归档的标准化协作流程，不归档即为未完成 |
| 负向反馈 | 防止系统崩溃的自我校准机制，不是惩罚而是免疫系统 |
| 反脆弱 | 系统从冲击中学习、从错误中进化，而非在保护中停滞 |
| 硬约束 | 嵌入操作流程的强制检查点，比提示词中的"请不要"更有效 |
| 自主学习 | 系统在空闲时段主动探索、验证和沉淀知识的能力 |
| 情绪变量 | 系统对决策者精力状态的感知和响应，确保决策在充分信息下做出 |
| 工程容错性 | 系统在角色缺失、信息丢失时的兜底和恢复能力 |
| 理论容错性 | 框架的思想本身接受挑战和修正的开放程度 |
| 传统 AI Agent 使用 | Trinity 框架 |
|---|---|
| 人→AI→人（串行） | 人⇄规划 AI⇄执行 AI（闭环） |
| AI 之间不沟通，各管各的 | AI 之间有标准化的信息传递协议 |
| 每次对话都是新的开始 | 知识持续累积，能力持续进化 |
| 人的记忆力是瓶颈 | 知识仓库是共享记忆 |
| 依赖特定 AI | 任何 AI 都可接入，知识主权在人手中 |
| AI 出错后下次可能再犯 | 错误被结构化记录，形成决策规则 |
| 沟通协议模糊（自然语言） | 沟通协议标准化（六步闭环 + 模板） |
| 知识锁在对话历史中 | 知识沉淀在可复用的知识仓库中 |
| 无系统免疫机制 | 负向反馈 + 反脆弱设计防止崩溃 |
| 假设用户永远是理性的 | 情绪变量感知用户状态，适配沟通策略 |
Trinity 与 LangGraph、CrewAI、AutoGPT 等项目的本质区别，不在于技术实现，而在于决策权的分配。
- LangGraph 和 CrewAI 聚焦于 Agent 之间的任务分配——谁做什么、什么顺序做。它们是在 AI 之间分配工作。
- AutoGPT 和 BabyAGI 强调 AI 自主性——AI 自己设定目标、自己执行。它们是在减少人的参与。
- Trinity 聚焦于决策权的分配——什么决策由人做、什么决策由 AI 做、什么决策需要人确认后才能执行。它是在定义人与 AI 之间的权力边界。
| 项目 | 核心问题 | 回答方式 |
|---|---|---|
| LangGraph | 如何让多个 AI 协同工作？ | Agent 之间的任务图编排 |
| CrewAI | 如何让 AI 团队高效合作？ | 角色定义 + 任务委派 |
| AutoGPT | 如何让 AI 自主完成任务？ | 自我分解目标 + 循环执行 |
| Trinity | 如何在 AI 能力增长时让人保持控制？ | 人与 AI 之间的决策权分配 |
Trinity 的独特价值： 当 AI 的能力越来越强，最重要的不是让 AI 能做更多事，而是确保人始终拥有最终决策权。Trinity 不是在 AI 之间分配任务，而是在人与 AI 之间分配决策权。这个定位决定了它与所有现有 AI Agent 框架都不相同。
Trinity 框架是一个方法论框架，有其适用范围和边界。了解这些局限性可以帮助你更好地判断框架是否适合你的场景。
知识仓库需要持续维护。每次任务后归档、定期校验信息一致性、更新能力清单——这些都是时间和精力投入。如果维护时间超过产出的 10%，说明流程需要简化，或者框架不适合当前场景。
Trinity 要求决策者具有较高的元认知能力——能够意识到自己的认知局限，愿意在决策前接受外部视角的审视。如果你习惯于"想到就做"的工作方式，Trinity 的缓冲层机制可能会让你感到不习惯。
AI 能力在快速进化。今天需要三层角色分离的协作模型，可能在未来某个版本中变为两层甚至一层。框架设计了每月一次的定期复审机制来应对这种变化——如果某个角色可以被合并或简化，就需要及时调整。
- 极其简单的单步任务（如"检查文件大小"、"阅读这个文件"）——走完整六步闭环会显得繁琐
- 对实时性要求极高的场景（如毫秒级的响应需求）——缓冲层的引入会增加延迟
- 纯娱乐或闲聊 —— 框架的严肃性设计不适合随意的对话
- 情绪感知的准确性：自适应规划中的精力感知目前仍依赖对话中的间接线索，准确率不够稳定
- 跨语言协作：框架目前只支持中文和英文，其他语言的支持尚在探索中
- 多决策者协作：当多个决策者共用同一个框架时，知识仓库的冲突分辨机制尚未成熟
Trinity 在工程层面和理论层面都有完整的容错设计，但它们的性质不同。
工程容错性是指系统在角色缺失、信息丢失、决策偏差时如何兜底和恢复：
- 角色缺失预案：规划者宕机了怎么办？执行者越界了怎么办？（见 反脆弱：角色缺失预案）
- 信息丢失兜底：知识仓库损坏了怎么重建？每条信息有几个备份？（见 反脆弱：信息丢失兜底）
- 决策偏差纠正：发现错误决策后怎么回滚？（见 反脆弱：决策偏差纠正）
工程容错性做了，理论和实证都做了——有自检清单、脉搏日志、信息保真机制、知识仓库备份策略。这部分设计方案在 docs/反脆弱设计.md 中有完整记录。
理论容错性是指框架的思想本身如何接受挑战和修正。每个核心假设都标注了置信度，并在设计上预留了修正空间：
- 角色分离是否真的有效？ 标注为"🟢 已验证"——15 项检查点 100% 通过。但框架设计为可以随时增加验证条件。
- 缓冲层是否真的降低风险？ 标注为"🟡 需持续验证"——有单点数据支撑（违规率从 70% 降至 5%），但需要更多跨场景数据。
- 知识仓库是否真的提升效率？ 标注为"🟡 推测"——在小范围实验中有明显优势，但在大规模场景下尚未验证。
- 三层角色分离是否比两层更好？ 标注为"🟡 推测"——理论上有优势，但需要长期对比验证。
Trinity 的理论容错设计体现在：
- 每个结论标注置信度（🟢 高 / 🟡 推测 / 🔴 不确定），区分"已验证"和"推测"。
- 每个决策规则标注来源，可追溯到具体实践。没有来源的规则被视为"暂定"。
- 核心原则保留修订历史，不是删除旧版本而是标注"已被新规则替代"——让思想演化过程可追溯。
- 每月一次框架复审，检查假设是否仍然成立。如果某个核心假设被证伪，不是掩盖它，而是把它结构化为学习记录。
Trinity 不怕被挑战，因为挑战本身是它进化的动力。
详见 docs/局限性.md。
- 一个能够访问互联网的 AI 系统（DeepSeek / Claude / GPT 等）
- 标准 Markdown 文件读写能力
# 1. 克隆仓库
git clone https://github.com/Buzhidao11145/Trinity-Collaboration-Framework.git
# 2. 阅读核心原则
cat Trinity-Collaboration-Framework/核心原则.md
# 3. 将核心原则.md 粘贴给你的规划者 AI
# （告诉它："这是我们的协作规则，请以此为基础理解后续所有任务"）
# 4. 创建你的第一个任务模板
cp templates/任务提示词模板.md ./my_first_task.md
# 5. 开始协作
# 告诉你的规划者："开始第一个任务——搭建知识仓库"- 初始化知识仓库 — 创建
decisions/、capabilities/、learning/等目录 - 编写第一条决策规则 — 回顾你过去 3 次与 AI 协作中的失败经历，提炼为规则
- 生成第一份指挥官简报 — 让规划者总结当前知识库状态
- 封装第一个 Skill — 选一个你经常执行的操作，标准化为可复用的 Skill
| 场景 | 为什么适用 |
|---|---|
| 复杂任务的 AI 协作管理 | 六步闭环确保长流程不丢失上下文 |
| 多 AI Agent 的调度与约束 | 缓冲层防止 Agent 越权行动 |
| 个人知识体系的系统化积累 | 知识仓库持续沉淀，不依赖对话历史 |
| 安全研究中的风险防控 | 自检清单 + 预警机制在高危操作前提供安全防线 |
| 团队协作中的 AI 接入 | 标准化模板降低沟通成本，知识主权确保信息不流失 |
| 学习与成长 | 失败知识库 + 决策规则让每次错误都转化为可复用的经验 |
欢迎贡献新的决策规则、Skill 模块或实战案例。请确保：
- 所有内容已脱敏（不含密钥、PII、内部系统信息）
- 决策规则标注来源背景和验证状态
- Skill 包含完整的输入输出规范
- 学习成果包含问题描述、根因分析、学习要点和相关决策规则
- 🧠 新增决策规则 — 来自真实协作失败的教训
- ⚙️ 新增 Skill 模板 — 标准化你的高频操作
- 📚 新增实战案例 — 附上环境配置和执行结果
- 🐛 修复规则漏洞 — 发现规则不适用于某些场景时
MIT License — 可用、可改、可分发。详情见 LICENSE。
Trinity AI 协作框架 v1.2 · 2026 年 6 月 "在能力和行动之间，留一个思考的间隙。"