个人 Agent OS：如何把 Skills、Tools 与 Evals 组织起来

当你开始积累 Prompt、脚本、项目规则、工具和失败案例时，很快会遇到一个新问题：它们散落在不同项目、不同客户端和不同聊天里。

模型升级时，你不知道哪些经验还有效；换一个项目，又要重新解释安全边界和工作方式；某次解决得很好的问题，过两个月已经找不到当时的流程。

“个人 Agent OS”想解决的不是再做一个操作系统，而是给这些资产一个可以持续演进的组织方式。

一、它不是一个大而全的产品

个人 Agent OS 不一定需要 Web 控制台、数据库或复杂编排框架。对多数开发者而言，它可以先是一套版本化目录和工作约定：

agent-os/
├── policies/          # 上下文、审批与安全原则
├── skills/            # 高频工作方法包
├── tools/             # schema、适配器、contract tests
├── harness/           # 运行、状态恢复、可观察性
├── orchestration/     # 单 Agent、并行、审查模式
├── evals/             # 真实失败、grader、运行报告
└── templates/         # AGENTS.md、progress.md、任务契约

它的核心不是目录长什么样，而是每个经验都知道自己该去哪里：稳定原则进入 policy，重复流程进入 Skill，确定性检查进入脚本，真实失败进入 Eval，当前进度进入状态文件。

二、先建立三项最有复利的资产

如果未来一段时间只能认真做三件事，我建议优先级是：

Skill Library + Harness + Eval Dataset

Skill Library：把经验变成方法

它减少重复解释，让新模型、新项目也能继承你验证过的工作方式。

Harness：把方法放进可靠环境

它让 Agent 默认检查、记录状态、遵守权限并在失败时恢复，不需要每次靠聊天提醒。

Eval Dataset：证明改进是真的

它让你知道模型升级、工具调整或多 Agent 编排到底有没有提高真实任务成功率。

模型和客户端都是公共能力；这三类资产越贴近你真实任务，越难被简单复制。

三、不要从“搭平台”开始，从任务分布开始

很多人一听到 Agent OS 就想先接入所有工具、建记忆库、做多 Agent 面板。更有效的起点是先观察自己一周内真正反复出现的工作。

可以做一张非常小的表：

任务类型 一周频率 常见失败 当前验证 是否值得资产化
发布技术文章 2 次 漏构建、混入敏感信息 手动检查 是：发布 Skill + 脚本
修复线上 bug 1 次 未稳定复现就改 测试不稳定 是：Debug Skill + Eval
临时头脑风暴 多次 无 不需要 否：保持聊天即可

这张表的作用，是阻止你把低频、低风险、无法标准化的事情也强行自动化。

四、一个 90 天的务实路线

第 1 个月：建立基线

  • 选择三类最常做的任务；
  • 各收集五到十个真实案例；
  • 为每类任务写清成功标准和风险边界；
  • 记录当前用时、人工介入与失败类型。

产物不是平台，而是第一版任务契约、失败分类和小型评测集。

第 2 个月：把重复经验做成 Skill

  • 为三类任务各写一个最小 Skill；
  • 把构建、格式、敏感信息检查等确定性步骤移到脚本；
  • 每次失败只补一条有证据的规则；
  • 用已有案例检查 Skill 是否真的减少遗漏。

第 3 个月：补 Harness 和恢复能力

  • 统一项目入口和 AGENTS.md 模板；
  • 为长任务增加状态恢复文件；
  • 给高风险操作定义审批与停止条件；
  • 为新模型、新工具或新编排跑回归集。

三个月后，你应该拥有一套会随着真实工作变好的基础设施，而不是一个只在演示中好看的 Agent 面板。

五、用成熟度判断下一步，而不是跟风加功能

阶段 特征 下一步
L0 聊天使用 临时提问，难复现 保存典型任务与完成标准
L1 Prompt 工作流 有模板，但要人工推进 加入验证与审批边界
L2 Tool-enabled Agent 能多步执行，但容易混乱 做上下文和工具设计
L3 Skill + Harness 流程可复用、能恢复 建立 Eval 与 trace
L4 Eval-driven 变化可比较、失败能回归 优化跨项目复用与编排

成熟度不取决于用了多少模型、装了多少插件或开了多少 Agent。更重要的是：任务能否复现，失败能否定位，结果能否验证，系统中断后能否恢复。

六、最后的原则：经验要进入正确层次

当下一次 Agent 协作出现问题，不要立刻往 Prompt 末尾追加一句“务必注意”。先问：

这是目标不清，还是上下文选错？
是重复方法没有 Skill 化，还是工具设计太模糊？
是 Harness 没有验证，还是权限系统太松？
是一次真实失败，能否进入 Eval 防止回归？

能这样归因时，你就不再只是在“使用 AI”。你是在持续设计一套能放大自己判断力的工作系统。

AI 实现摘要

  • 要解决的问题：将任务契约、上下文规则、Skills、工具、Harness 与评测集组织为可跨项目复用、可持续演进的个人 Agent 工作系统。
  • 适用版本与前置条件：适用于长期使用 Agent 进行开发、写作、调研或自动化的个人与小团队；建议使用版本控制管理资产。
  • 输入、输出与验收标准：输入为真实任务分布与失败案例；输出为最小目录、三类优先资产与阶段性路线。验收标准是关键任务更可复现、可验证、可恢复，且改进有评测证据。
  • 文件改动清单：可创建独立 agent-os/ 仓库或将 policies/、skills/、evals/、templates/ 放入现有工作区。
  • 完整命令：无通用命令。每项资产应绑定项目实际的构建、测试、验证或评测命令。
  • 测试步骤与预期结果：选择三类高频任务，连续三个月记录任务成功、人工介入、失败回归和成本；预期形成可复用 Skill、恢复点和至少一组真实 Eval。
  • 常见错误、回滚方法与安全边界：不要将敏感数据、生产凭据或无验证猜测沉淀为长期资产。所有规则、Skill 和工具变更应可审查、可版本化、可回滚。