GitHub：
Randy0609/context-hub·v0.1-draft
为超级个体准备的、本地优先的 Harness Engineering（智能体约束工程）开源起点。
它帮助你把散落在文档、聊天、脑子和不同 AI 工具里的目标、知识、规则、工作流与反馈，组织成一套 Agent 能找到、能执行、能验证、能持续改进的工作环境。
人定义目标与责任
↓
Context Hub 提供最小可信上下文与规则
↓
Agent 在授权范围内执行
↓
测试与人工验收结果
↓
反馈进入下一轮，但不自动篡改长期原则
事实边界
- 当前仓库是项目初稿，不是已经可安装的正式产品。
- 文中的架构、分层和建设路径属于项目判断，仍需真实用户验证。
- 本项目不承诺“一个人替代一家公司”，也不承诺固定的效率、收入或成本结果。
- GitHub 仓库名为
context-hub，项目展示名为Randy Context Hub。- 项目采用 MIT License；该许可证允许复用与修改，但不构成效果保证。
很多人已经拥有多个 AI 账号、Prompt、自动化和知识库，但每次开始任务时仍然会遇到同样的问题：
- AI 不知道你是谁、真正要什么；
- 重要背景散落在不同文件和聊天记录里；
- 旧结论和新事实混在一起；
- Agent 有工具，却不知道什么时候可以使用；
- 一次任务做得不错，下一次仍要从头解释；
- AI 自己说“完成了”，但没有可检查的验收证据；
- 自动化越多，错误、隐私和失控风险也越大。
问题不只是模型能力，也不是少写了一个 Prompt。
缺少的是模型外部的一整套工作环境：目标、上下文、约束、工具、执行循环、验收、记忆和反馈。这就是本项目所说的 Harness Engineering。
本项目暂时把它翻译为：
智能体约束工程：通过设计 Agent 周围的目标、上下文、工具权限、工作流程、验证机制和反馈系统，使它能够在真实任务中更可靠地工作。
这里的“约束”不是把 AI 绑死，而是把人的判断变成 Agent 可以理解和执行的环境：
- 去哪里；
- 为什么去；
- 可以使用什么；
- 哪些事情不能做；
- 什么结果才算完成；
- 出错时怎样停止、求助和回滚。
OpenAI 在其 Harness Engineering 实践中强调：人负责引导，Agent 负责执行；仓库知识应成为可读取、可版本化的记录系统；入口文件应该是地图，而不是塞满全部知识的说明书；规则还需要通过测试、工具和结构被机械执行。该案例来自软件工程，本项目尝试把这些原则推广到超级个体的内容、研究、运营、产品和个人业务工作中。后半句是本项目判断，不是 OpenAI 的原结论。
Context Hub 不是完整的 Agent，也不是普通网盘或“第二大脑”。
它是 Harness 的上下文与规则中枢：
- 登记哪些内容是当前事实、历史决定、个人偏好、项目状态或工作方法；
- 记录来源、时间、有效范围、隐私等级和替代关系；
- 根据具体任务选择最小必要上下文；
- 把上下文、规则、Skill、验收和警告编译成任务包；
- 保存人工验收与修订原因；
- 只有经过确认的经验，才允许升级为长期记忆、规则或 Skill。
| 概念 | 解决的问题 |
|---|---|
| Prompt | 这一次怎样向模型表达要求 |
| Context | 这一次任务需要知道什么 |
| Skill | 一类重复任务按什么方法执行 |
| Agent | 谁在调用模型、工具并推进任务 |
| Harness | Agent 周围的完整工作环境与控制系统 |
| Context Hub | Harness 中负责知识、规则、来源和任务上下文的中枢 |
超级个体不是一个什么都会、可以独自替代整家公司的超人。
本项目把它定义为：
一个拥有清晰判断力，并能通过 AI、知识、工作流和反馈系统，持续扩大自己行动范围的人。
适合本项目的人：
- 创业者、自由职业者、内容创作者和独立开发者；
- 同时使用 Codex、Claude、ChatGPT 等多个 Agent 的人；
- 已经积累 Markdown、Obsidian 或项目文档，但难以让 AI 稳定使用的人；
- 想从“一次对话”走向“可重复交付”的人。
暂不优先服务大型组织的复杂权限、审批和合规场景。
07 学习治理层 反馈、记忆升级、Skill 毕业、垃圾清理
06 验收证据层 测试、人工验收、来源、失败样例
05 执行循环层 任务卡、状态、暂停、升级、回滚
04 能力工具层 Skills、工具、权限、沙箱、连接器
03 上下文记忆层 项目状态、事实、决定、偏好、证据
02 宪法权限层 红线、授权、隐私、责任边界
01 目标身份层 我是谁、服务谁、当前最重要的事
模型位于这七层之中，而不是系统的全部。
先回答：我是谁、为谁创造价值、当前最重要的目标是什么、哪些事情不值得做。
明确什么可以自动做、什么必须先问、什么永远不能做，以及最终责任由谁承担。
把当前事实、历史决定、项目状态、个人偏好和原始证据分开保存，并给内容增加日期与状态。
Skill 负责“怎样做”，工具负责“用什么做”，权限决定“能做到哪一步”。
任务从接收、澄清、计划、执行、检查、汇报到完成，都有可观察状态；失败和转人工不是异常设计之外的事故，而是正常路径。
不能只问 Agent “你做好了吗”。应事先定义完成标准，并用测试、来源、截图、差异或人工验收证明结果。
保存成功与失败，但不把每次输出都升级成长期规则。持续删除过期上下文、冲突规则和没有价值的自动化。
my-context-hub/
├── AGENTS.md # 给 Agent 的短入口地图
├── OWNER.md # 使用者、目标与稳定偏好
├── CONSTITUTION.md # 权限、红线和责任
├── MEMORY.md # 长期记忆索引，不是聊天归档
├── context/
│ ├── facts.md # 已核实事实与来源
│ ├── decisions.md # 决定、原因与替代关系
│ └── feedback.md # 人对 Agent 的明确纠正
├── projects/
│ └── example/
│ ├── README.md # 项目目标和入口
│ ├── STATUS.md # 带日期的当前状态
│ └── evidence/ # 可追溯证据
├── skills/ # 经过真实任务验证的方法
├── tasks/
│ ├── active/
│ └── completed/
├── evals/ # 验收标准和失败样例
└── adapters/ # Codex、Claude 等运行入口
AGENTS.md 应该是一张地图，而不是百科全书。Agent 根据当前任务逐层读取，不应该默认吞下整个知识库。
不要从“做一个万能 Agent”开始。选择一个每周重复、结果能被你判断、失败成本可控的任务。
示例：把三份访谈笔记整理成一份有来源的选题建议。
记录目标、最终验收人、不可委托判断和隐私边界。AI 可以执行，但不能替你承担真实世界后果。
只放完成该任务必需的事实、案例、风格要求和历史决定。每条重要事实尽量带来源、日期和有效状态。
写清触发条件、输入、步骤、输出、合格标准、禁止事项和常见失败。不要把一句 Prompt 命名为 Skill。
先只开放任务所需的最小权限。读取、草拟、修改、发布和付款不是同一个权限等级。
在执行前定义什么叫通过、修改或拒绝。至少保存一组失败样例。
记录人改了什么、为什么改。一次结果只是一条事件；重复出现并经人确认后，才升级为规则或 Skill。
详细模板见 docs/HARNESS-BLUEPRINT.md。
| 能力 | 当前状态 | 进入下一状态的证据 |
|---|---|---|
| 公开产品定义 | draft |
外部读者能准确复述项目解决的问题 |
| Harness 建设蓝图 | draft |
至少 3 位非作者按蓝图完成最小目录 |
| Starter 模板 | planned |
能被陌生人复制并跑完一个任务 |
| Context 校验器 | planned |
能发现断链、过期、冲突和隐私风险 |
| Context Package 编译器 | planned |
能按任务和预算生成可追溯上下文包 |
| Codex / Claude 适配 | planned |
同一任务包能被两个 Agent 消费 |
| 公开参考案例 | planned |
使用合成或获准数据，含成功与失败证据 |
planned 不是已实现。
- 不做 Prompt 合集或 AI 工具导航；
- 不把“多个聊天窗口”包装成 AI 团队；
- 不默认上传用户知识库；
- 不默认开启遥测；
- 不把全部笔记向量化后称为理解用户；
- 不允许 Agent 自动改写宪法、长期人物记忆和核心 Skill；
- 不用 Randy 的客户数据、账号配置和未公开商业资料做公开样例；
- 不把一次可运行演示写成已经产生业务价值。
andrewyng/context-hub主要面向编码 Agent，提供可检索、版本化的 Markdown 文档与本地注释机制。
Randy 版借鉴“开放 Markdown、可检查来源、按需获取、跨会话反馈”的思路，但目标不同：
- 原项目首先回答“Agent 去哪里获得较可靠的技术文档”；
- 本项目首先回答“一个人怎样建成自己的 Agent 工作环境”。
本项目当前是独立设计初稿，不是原项目官方版本，也不代表与原作者存在合作关系。
Build Your Own AI Team关注怎样把真实业务任务设计成可运行、可验收的 AI 岗位与团队成员。
本项目关注更底层的个人 Harness：目标、上下文、权限、任务循环、验收和记忆怎样组织。未来前者可以提供“岗位与案例”，后者提供“运行这些岗位的个人工作环境”。
计划开源：
- 方法、Schema、模板和校验规则；
- 合成数据示例；
- 可复现的成功与失败案例；
- 本地运行的索引和上下文编译工具。
不计划开源：
- 用户的原始笔记和聊天记录；
- 客户、粉丝、员工或合作方信息；
- 密钥、Cookie、Token 和内部配置；
- 未公开的商业策略和财务数据；
- 未经人工确认的模型推断。
项目不会因为“文件齐了”就宣称完成。第一版至少需要：
- 一位使用者用自己的本地资料完成一个真实任务；
- 从任务到上下文、执行、验收、反馈全链路可追溯；
- 能明确展示一次失败以及怎样被发现；
- 原始资料保持只读，派生索引和任务包可以删除重建；
- 三位非作者能从干净环境复现；
- 至少两个不同 Agent 能使用同一份 Context Package；
- 公开样例通过隐私、来源和许可证检查。
现在最需要的不是更多功能，而是更真实的问题和失败案例：
- 你每周反复向 AI 解释什么？
- 哪类任务最容易因为缺上下文而失败？
- 哪些决定永远不应该自动交给 Agent？
- 你怎样判断结果真的可以交付？
- 哪条旧经验正在误导今天的 Agent？