执行地图
Project、Thread 与 Orb 回答的是三个不同问题。
Amp Project 标识代码库与共享 runtime 设置；Thread 保存一次任务的 prompts、replies、tool calls 和文件变化；Orb 是实际执行工作的隔离远程机器。知识记录可以引用这三层，但不能把任何一层直接当成已接受结论。
| Amp 层 | 负责什么 | 持久性边界 |
|---|---|---|
| Project | Repository、项目设置、共享执行默认值 | 管理代码库，不管理每条业务事实 |
| Thread | Conversation、tools、files、changes、handoff | 可以分享、归档、导出或删除 |
| Orb | 远程机器、filesystem、services、runtime proof | 执行环境，不是 policy authority |
| Reviewed record | 已接受结果、证据、owner、freshness | 只能通过可审核提议变更 |
Thread 边界
可分享的 Thread 是 provenance，不会自动变成真相。
Amp Thread 记录 prompts、replies、tool calls、files、跨设备 handoff，并能从 commit 回到原始任务。它可以是 private、workspace、group 或 unlisted。保留准确 Thread URL 作为证据，但只提升其他人真正需要的 decision-sized result。
指令与扩展层
运行指导、复用流程、runtime code 与已接受事实必须分层。
Amp 为不同工作加载不同 surface。把它们都塞进一个大文件，会同时制造过期事实和过宽权限。
| Surface | 适合保存 | 不适合保存 |
|---|---|---|
| AGENTS.md | Repository layout、commands、conventions、review steps | 客户、发布或 incident 的变化状态 |
| Skill | 带 scripts 与 references 的聚焦流程 | 自动接受流程最新输出 |
| Plugin | Tools、commands、events、UI、policy hooks | 静默拥有 canonical records |
| MCP | 外部 tools、resources、authenticated calls | 把 tool response 当成已批准知识 |
| Busabase | 可审核 records、Docs、files、Skills、Apps | 替代 repository-local code review |
扩展边界
Skills 延迟加载流程，Plugins 执行代码，MCP 连接外部系统。
Amp 建议把聚焦 MCP server 放进 Skill，让 tools 只在相关流程加载后出现。Plugin 可以注册 tools、commands、events、UI 与 Skills，但会在 active environment 执行代码。Plugin 是 executable software，Skill 是 versioned workflow，MCP response 是仍需解释的证据。
Lazy-loaded instructions、scripts、references、optional MCP
带 tools 与 lifecycle events 的 executable code
有 scoped tools 与 auth 的 local/remote server
这些层都不能自行接受的 reviewed outcome
Orb 边界
远程执行会改变 credentials 与 tools 应该放在哪里。
Orb 是新的远程环境，可以在笔记本关闭后继续工作。机器上的本地 Amp 设置不会自动出现。Project-safe config 放进 repository，browser OAuth 使用 remote MCP definitions，secret 放在指定 secret store，不写进 committed config。
可使用本机 Amp config 与 browser OAuth
使用 repository config、Orb secrets 或 remote MCP definitions
跨 clients 保存 conversation 与执行引用
只跨任务和团队保存已审核 claim
证据包
保留足够 Amp 运行证据，让结论以后仍可被质疑。
精简 evidence bundle 应标明 Project、Thread、执行位置、repository revision、instructions 与 extensions、关键 tool calls 和 verification，不需要复制整段对话。
project_refAmp Project 与 repository URLthread_ref稳定 Thread URL 或 IDexecutorOrb、runner 或 local CLIinstruction_refsAGENTS.md 与相关 Skill revisionstool_trace关键 Plugin 或 MCP callsrepository_refBase branch、commit、diff、shipped revisionverificationTests、portals、screenshots 或 external readback
知识契约
提升一条即使 Thread 不再方便访问也能独立理解的结果。
记录必须说明发生了什么、证据是什么、谁接受，以及什么时候会过期。后续 Agent 不需要继承无关 prompts 或宽泛 Orb 权限。
knowledge_key可复用 claim 的稳定身份proposed_stateAmp 产出的精简结果source_refsThread、code、Docs、外部证据scope受影响 projects、services 或 teamsowner负责接受的人decision接受、有条件、拒绝或已替代verified_at最近证据检查next_review_at下一次时效检查不要提升
绝大多数 Thread 内容应该留在执行历史中。
只有会影响当前任务之外决策的内容才值得进入审核。
探索路径、失败命令、临时备注、中间假设
源码、配置、测试、repository-local instructions
架构决定、已验证 runbook、发布事实、incident 结论
没有证据、owner、scope 或 freshness 的 claim
实际问题
Amp 知识库常见问题
Busabase 会取代 Amp Threads 吗？
不会。Threads 保存任务历史与协作；Busabase 保存少量已审核结果。
每个 Amp Thread 都要建记录吗？
不用。只有结果会指导 Thread 之外的后续工作时才提议。
Unlisted Thread 能成为唯一来源吗？
可作 provenance，但还要保留不受 visibility 变化影响的 code、test 或外部证据。
Amp Skill 会强制审核吗？
Skill 指导执行；权限与 Change Request 才决定记录是否 canonical。
Orb 会自动使用本地 MCP 设置吗？
不会。当前 Amp 文档明确区分 local config 与适用于 Orb 的 repository/remote definitions。
从一个 Thread 开始
把一个已验证的 Amp 结果转成团队可审核知识。
选择完成的任务，附上 Thread 与 repository evidence，让责任人只审核一条有边界的提议。