文档范围
各厂最近都在补同一类缺口：下次开工时，人和 Agent 不必把项目地图、规则和验证入口再讲一遍。有的叫 Workspace，有的叫 Projects、Memory、Skills、AGENTS.md 或 Harness（围绕模型组织上下文、工具、权限和验证的那一层运行装置）。名字乱，指向却接近：一份可共享、可版本化的稳定资产。
本文只写个人这一层。它回答的问题是：我自己的 Agent 在这个项目里应当依据哪些已确认事实、能执行哪些动作、怎样证明完成、哪些经验值得留下。它用文件夹组织，由我长期维护，被多个需求、多个仓库和多个 Agent 客户端共同消费。一次任务结束后，执行现场可以归档；经过我确认的项目能力继续服务下一次任务。
后文单独出现的 Workspace，默认都指这一层。团队共享、活文档共编、跨机器调度是下一篇文章的事。ChatGPT Space、Team Mesh 以及公开检索不到的私域方案，只在对照里点到边界，不作为本文的实现标准。
建设是否有效，不看目录是否填满，而看真实需求能否走完 Spec、Coding、Review、Verify，以及确认后的经验能否被后续任务复用。
产品里那些也叫 Workspace 的东西
公开文档里至少能分出几类对象。先确定它约束什么，再讨论目录、Worktree、Session 或权限。同一套 Agent 系统可以同时具有它们，但不能共用同一个生命周期。
| 它实际在管什么 | 生命周期 | 公开产品中的例子 | 和本文的关系 |
|---|---|---|---|
| Agent 当前能看见和修改哪些目录 | 随 IDE 窗口或项目挂载 | Gemini Code Assist Agent Mode；Cline Multi-Root Workspaces | 代码视野，不是稳定资产 |
| 这一次任务在哪里运行 | 随 Issue、Quest 或 Execution 创建归档 | 通义灵码 Quest 的 Local / Worktree；OpenHands Workspace | 对应本文的任务现场 |
| 每次开工应遵守什么、重复任务怎么做 | 随仓库或用户配置版本 | OpenAI AGENTS.md；Claude CLAUDE.md；Skills | 入口地图和做法包，不是全部 |
| 个人偏好和本次观察如何带到下次 | 随用户、机器或 Memory Drive | Grok Build Memory；Codex Memories | 候选增量；默认不是已确认事实 |
| 人与 Agent 共编的活文档 | 文档一直在；私聊和 Memory 默认不随分享走 | ChatGPT Space + Pages | 团队文再写 |
| 机器、运行时、分身、共享任务如何调度 | 随工作区成员和机器在线状态 | Team Mesh / Multica | 团队编排，不是项目地图 |
| 谁能进、怎么计费 | 随组织或平台账号 | 腾讯云工作空间；ChatGPT Business Workspace | 租户外壳 |
图 1：代码目录、任务现场、个人稳定资产和产品里其他叫 Workspace 的层，不能共用同一个词。本文只建设「稳定资产」这一列。
值得借的设计理念，不值得把对象写串：
- OpenAI 在 Harness engineering 里把短
AGENTS.md写成目录，把可验证知识放到版本化的docs/。入口规则不是 Workspace 全部。 - xAI Memory 明确排除任务状态、试探性结论、Secret，以及仓库和文档里已经有的内容。跨会话记忆可以减少重复解释，但不能代替仓库地图和验收标准。
- 阿里 Quest 把 Local 与 Worktree 分成两种执行环境。那是任务现场怎么跑，不是项目真相存在哪。
- 美团 CatPaw 允许把高频流程录制成技能。那是能力沉淀；进入默认真相之前，仍然需要来源和确认状态。
这些产品补的是客户端侧的积累机制。个人 Workspace 要补的，是公开客户端默认不会替你维护的那包项目地图：跨仓路由、验收入口、以及一次任务结束后哪些结论可以留下。
个人研发现场里缺的是什么
是否需要这一层，取决于 Agent 在真实任务里反复卡在哪里。
| 现场 | 缺失的能力 | 建设后应出现的变化 |
|---|---|---|
| 每次任务都要重新解释背景、贴链接、补充历史坑点 | 项目事实散落在人脑、会话和零散文档中 | Agent 按稳定路由查询已确认事实 |
| 能生成代码，却不知道该跑哪些测试 | 构建、测试和验收没有变成可执行入口 | Script、Skill 固化验证路径 |
| 跨仓任务不敢交给 Agent | 仓库职责、依赖、分支和读写边界不清楚 | 先有 Repo 路由，再在受控范围内修改 |
| 同类故障反复排查，结论留在旧对话里 | 排障过程没有形成可复用资产 | 从 Session 提炼候选经验，经确认后回写 |
| Skill 和文档不断增加，却不知道是否有效 | 缺少跨任务的命中与结果 | 记录资产是否改善验证和交付 |
这些问题不能只靠换更强的模型解决。模型看不到的事实、不能执行的动作、没有定义的验收标准，都属于个人 Workspace 还没补上的缺口。
因此目标不是「Agent 知道更多」，而是让它逐步具备四件事：
知道去哪里查 → 知道如何执行 → 知道怎样证明完成 → 知道哪些经验值得留下缺的通常不是这一次怎么改文件，而是下一次新 Session 是否还要口头补同一套已经确认过的项目规则。
个人 Workspace 的定义
个人 Agent Workspace 是：面向一个项目，组织 Agent 所需上下文、工具、流程、验证入口和经验回写机制的长期操作空间。
它不是新建一个 Git 仓库，也不是把多个业务仓 clone 到同一目录。仓库只提供代码可见性。缺少业务语义、修改边界、验证入口和回写门槛时，Agent 仍然没有可积累的工作方式。
| 常见做法 | 它实际提供了什么 | 为什么还不够 |
|---|---|---|
| 新建一个代码仓库 | 容器 | 不自动产生知识、工具、流程和验证 |
| 把多个业务仓库 clone 到一起 | 代码可见性 | 没有说明职责、读写边界和交付条件 |
写一份 Prompt、README 或 AGENTS.md | 规则入口 | 不能替代实时查询、确定性脚本和真实验证 |
| 建一座文档库 | 静态知识 | 进不了「查询—执行—验证—回写」链路 |
| 打开一个 ChatGPT Project / Space | 对话或活文档容器 | 不自动等于仓库地图和验收证据 |
GEMINI.md、AGENTS.md、CLAUDE.md 仍然值得写。它们是入口规则，不是 Workspace 的全部。
五层资产与三个平面
分层用来发现能力缺口，不是要求先把所有目录填满。
| 层次 | 应保存或连接的内容 | Agent 得到的能力 |
|---|---|---|
| 代码层 | Repo 清单、职责、默认分支、依赖、读写边界、启动与测试入口 | 知道去哪个仓库、能改什么、如何运行 |
| 知识层 | 业务概念、架构、产品规则、接口契约、Spec、故障经验 | 先查已确认事实，不在任务中临场猜测 |
| 环境层 | 开发、测试和生产环境的部署入口、日志、监控、回滚方式 | 能进入真实环境验证和排障 |
| 工具层 | Scripts、Skills、Plugins、Hooks、CLI 和外部系统连接器 | 把高频做法变成可重复执行的动作 |
| 流程层 | Discuss、Spec、Coding、Review、Verify、Summarize 的产物与卡点 | 知道当前阶段、退出条件和失败后回到哪里 |
知识层的关键是查询路由，而不是把所有资料复制进同一个文件夹。长期有效的规则、架构和契约适合版本化保存。需求状态、日志、监控和环境运行状态应在使用时实时查询，并在索引中标明权威来源。
为了让任务可复现，每个任务现场固定消费稳定资产、Workflow 和工具的版本。实时查询不冻结成长期事实，但应记录来源、查询参数和时间。
环境说明与凭据必须分离。Workspace 可以保存如何申请、如何注入、如何验证权限，不应把 Secret 直接写进目录。
这五层可以整理成三个平面：
- 上下文平面：代码、知识和环境，回答项目是什么、事实在哪里。
- 能力平面：工具层，回答 Agent 能稳定执行什么。
- 治理平面：流程、验证、确认和度量，回答何时可以继续、什么可以长期沉淀。个人版的 Owner 就是自己；门槛不能因此取消。
图 2：缺少任何一个平面，Workspace 都会退化成资料库、脚本箱，或没有验收标准的自动化。任务现场在创建时消费这些能力；结束后只把经过确认的增量送回。
按哪包默认真相来切
切 Workspace，切的是 Agent 每次开工都会默认加载的那包已确认事实。范围太大，做 A 项目时会读到 B 的规则；范围太小，一个真实需求要跨多个 Workspace 才能改完。
默认按一个项目来切。这里的「项目」不是单个 Git 仓库，也不是整个硬盘，而是四项条件都能对齐的工作范围：
- 同一张仓库地图
- 同一套规则责任
- 同一圈权限
- 同一更新节奏
一个产品下的多个业务仓库，只要这四项对齐，仍应放在同一个 Workspace。一个人如果同时做条件明显不同的几摊工作，就应维护多个 Workspace。
- 应合并：一个客户端产品同时有应用仓、模块仓和 overlay 仓，但共用一张仓库地图、同一套启动和测试入口，规则也跟着同一产品版本更新。多仓仍是一个 Workspace。
- 应拆开：同一人既做客户端交付，也做离线数据分析。仓库入口、数据权限和规则更新频率都不同。做客户端时不应默认加载分析口径，跑分析时也不应默认加载客户端验收 Skill。
图 3：四项对齐时，共享的是已确认、已版本化的项目真相。任一项明显不对齐，就拆开；骨架用模板复用，不含项目事实的通用动作用 Plugin 复用。
个人版没有「领域 Owner 签字」，但每条稳定规则仍要能指出权威源：代码行为以受版本控制的代码和测试为准，需求语义以批准的 Spec 为准，接口以正式契约为准，环境状态以实时查询为准。来源冲突或超过失效时间时，Agent 应停止把它当成稳定事实。
拆开后，公共能力不要靠再做一个超级 Workspace 来复用：
| 复用物 | 是否包含项目事实 | 典型内容 |
|---|---|---|
| Workspace 稳定资产 | 包含。Agent 默认当真相 | 仓库地图、产品规则、验收 Skill |
| 个人模板 | 不包含。只提供空壳和卡点 | AGENTS.md 骨架、repos 索引结构、候选资产必填字段 |
| 通用 Plugin | 不包含。只提供通用动作 | 认证、沙盒、连接器 |
项目真相跟 Workspace 走。不要为了共用登录或审计，把两套项目事实放进同一份默认上下文。
研发交付闭环
目录和资产只是输入。交付闭环判断的是：一次真实需求能否按已定义的阶段、产物和退出条件做完。
理解目标
→ 查询稳定知识
→ 查询实时状态
→ 澄清并形成 Spec
→ 在任务现场编码和测试
→ Review 与修复
→ 真实环境验证
→ 交付与总结每个阶段都应定义四件事：输入是什么、要调用哪些能力、产物是什么、什么条件下才能退出。Verify 不能只写「运行测试」，还应指定环境、操作步骤、期望终态和证据格式。任何关键步骤失败，都应回到 Coding 或问题诊断，而不是用其他绿色信号抵消。
| 阶段 | 主要产物 | 最小退出条件 |
|---|---|---|
| Discuss / Spec | 已确认的目标、范围、约束和验收条件 | 未决问题已显式记录，需要人决策的前提已经确认 |
| Coding | Diff、实现说明、局部测试结果 | 改动符合仓库规则，相关检查可重复运行 |
| Review | 评审意见与修复记录 | 阻塞意见已处理，风险有明确结论 |
| Verify | 测试、真实请求、截图、日志或部署报告 | 每条验收条件都有对应证据 |
| Summarize | 交付摘要与候选经验 | 事实、临时现场和可复用增量已经分开 |
上述交付链路运行在任务现场中，但它消费的项目知识、规则和验证能力来自长期 Workspace。
任务现场不是另一份 Workspace
长期能力和单次任务现场必须分开。如果用页面或看板去调度 Codex、Claude Code，对象可以写成：
| 对象 | 职责 |
|---|---|
| 个人 Workspace | 保存 Repo 路由、知识索引、Skills、Workflow、验证规范与版本 |
| 需求卡片 | 保存目标、范围、优先级、验收条件和业务状态 |
| 任务现场 | 管理工作目录或 Worktree、终端、进程、Diff、PR 与证据 |
| AgentSession | 保存一次可恢复的连续交互上下文 |
| Run | 记录一次输入到完成、失败或等待干预的连续执行 |
需求容器也可以被产品叫成 Workspace，和本文不是一层。创建任务现场时应固定所消费的个人 Workspace 版本，避免任务跑到一半规则静默变化。派发成功不等于需求完成。
需求卡片与任务现场应使用两套状态机：
需求卡片：Backlog → Ready → In Progress → Review → Done
任务现场：
Provisioning → Running ↔ WaitingForUser
Running → Succeeded / Failed → Archived一个需求可以关联多个任务现场；一次执行失败不等于业务任务失败。Worktree 只是执行现场中的代码隔离组件，也不等于长期 Workspace。
图 4：需求消费个人 Workspace；在任务现场编码和验证；交付通过后现场归档。候选增量还要经过自己确认，才能发布到新的资产版本。
经验回写与稳定资产
交付结束后，Session、日志和 Diff 只是活动记录，不能自动变成下一次任务的稳定知识。更安全的回写链路是：
活动记录 → 候选增量 → 证据核对 → 自己确认
→ 发布新的 Workspace 版本 → 在后续任务中复用值得回写的内容通常包括已确认的业务规则、接口契约、稳定复现的故障结论、重复出现的操作步骤，以及可复用的 Skill、Script、Test、Hook 或模板。
每项候选资产至少需要：
| 字段 | 作用 |
|---|---|
source | 指向原始需求、Spec、日志、Diff 或验证报告 |
scope | 标明适用 Repo、模块、环境和任务类型 |
confidence | 区分已验证事实、可信推断和待确认线索 |
review_status | 阻止未确认内容进入稳定上下文 |
updated_at / revalidate_by | 支持版本比较、过期提醒和腐化巡检 |
还应区分三类对象：
- 事实源：代码、正式接口契约、已批准 Spec 和平台实时状态。
- 派生资产：概览、索引、操作指南和 Skill references，应能追溯或重新校验。
- 活动记录：Session、执行记录、日志和失败现场，用于审计和发现候选知识，默认不直接加载为稳定规则。
「自我进化」的合理边界是自动发现和起草，人负责确认事实、批准版本与撤回错误资产。没有这道门槛，Workspace 会把一次任务中的猜测放大到所有后续任务。跨会话记忆可以记住个人偏好，但不能绕过这道确认。
建设路径
分层、分流程不是二选一。
分层建设
L1–L3 是渐进建设模型，不是行业标准。每一级都应是能独立获益的稳定状态，可以长期停留。升级条件是更长的真实任务闭环已经稳定跑通，而不是目录数量增加。
图 5：L1 解决安全进入，L2 解决按流程执行，L3 解决真实验证和受控回写。
L1：Agent 能安全进入项目
最小资产包括项目说明、Repo 路由、读写边界、启动方式和一个基础验证入口。验收方式不是检查文档数量，而是让一个没有额外口头背景的新 Session 找到正确仓库、启动项目并跑通基础检查。
L2：Agent 能完成真实研发微循环
在 L1 上补充高频 Skill、确定性 Script、测试入口和 Review 卡点。验收是一项真实需求能完成「编码—测试—修复—评审」微循环，并保留可复查产物。任务现场必须钉住当前资产版本。
L3：交付有证据，经验可回写
补充真实环境验证、结构化报告、候选资产、确认门槛、版本发布和腐化巡检。验收不只是本次完成，还要观察确认过的资产是否在后续同类任务中再次命中。
分流程建设
不需要先为所有研发阶段设计完整系统。可以选择最频繁、代价最高或最容易验证的一条流程开始。
| 流程 | 优先建设的能力 | 验收信号 |
|---|---|---|
| Spec | 需求澄清规则、Spec 模板、验收条件和决策记录 | 后续 Coding 与 Verify 能直接消费同一份规格 |
| Coding | Repo 路由、环境启动、测试和问题诊断能力 | Agent 能在本地或隔离环境完成一项真实改动 |
| Verify | 可执行 Case、真实环境、断言和证据报告 | 每条验收标准都有独立结果，失败能回到实现 |
| Review | 评审规范、风险分级、意见回读与修复 | 代码和候选知识都经过确认 |
| Docs / Troubleshooting | Session 提炼、日志查询、故障模板和过期巡检 | 历史结论可追溯，并在后续任务中被正确复用 |
按流程建设的关键不是给每个阶段写文档，而是把入口规则放到 Agent 可发现的位置，把确定性动作放进 Script，把可复用做法放进 Skill，把阶段门槛放进 Workflow 或 Hook。
起步时，只选出 3 到 5 个「自己反复回答」的问题，先让新 Session 基于现有 Workspace 作答。回答不完整的部分再补资产，并把这些资产挂到实际流程中。这种问答验收比一次性编写完整手册更容易发现真实缺口。
最小可验证实现
第一版不需要先建设完整平台。选择一个真实项目和一条高频流程，按三个阶段验证即可。
下面是逻辑骨架，不是强制目录标准：
workspace/
├── AGENTS.md
├── repos/
│ ├── index.md
│ └── <repo>/
│ ├── overview.md
│ ├── setup.md
│ └── test.md
├── docs/
│ ├── glossary.md
│ ├── architecture.md
│ └── product-specs/
├── skills/
├── workflows/
├── evidence/
├── candidates/
└── executions/AGENTS.md只保存入口规则、路由和安全边界。repos/保存仓库地图和各仓说明，不是把业务代码复制进来。Agent 先在这里判断涉及哪些仓库，再读取各仓启动与测试方式。docs/保存稳定领域知识；实时需求、日志和环境状态通过连接器或权威系统查询。skills/与workflows/保存可执行做法和阶段卡点。evidence/保存证据索引或受控系统中的稳定链接，candidates/保存尚未确认的经验增量。executions/只索引这一次任务的工作目录、Session、钉住的资产版本和证据位置。任务结束后归档，不把活动记录提升为默认真相。
初始化可以由 Agent 扫描 Repo 结构、README、接口、测试入口和历史 Session，生成第一版索引与候选资产。自动化只负责降低起步成本；仓库边界、业务语义、凭据暴露和历史结论仍需人审核。
三个验收阶段
- 验证 L1：不额外解释项目，让新 Session 找到正确 Repo、启动项目并完成基础检查。
- 验证 L2：选择一项边界清楚的需求，跑通 Spec、Coding、测试和 Review；任务现场记录当时消费的资产版本。
- 验证 L3：用一个任务在真实环境完成验收、提炼候选资产并经确认发布；再用下一项同类任务验证它是否被正确复用。
用结果指标判断是否继续投入
文档数、Skill 数和调用次数只能说明发生了建设活动。更接近实际价值的指标包括：
- 每个任务需要人工补充背景的次数；
- 从需求创建到首个可评审结果的时间；
- 首次验证通过率和人工接管率；
- Review 后返工次数；
- 历史知识或 Skill 命中后的任务成功率；
- 候选资产确认后在后续任务中再次采用的比例。
这些指标需要固定任务类型和统计分母，并与建设前基线对照。单次成功、资产数量增长或调用次数增加，都不能单独证明 Workspace 有效。
建设约束
- 把 Workspace 做成文档仓库：资料没有查询路由、可执行动作和验证证据时，不会改善交付。
- 一开始填满五层：没有真实任务驱动的资产难以判断价值，也会快速过期。
- 让 Agent 自动写入稳定知识：自动提炼可以默认开启，自动批准不应默认开启。
- 把活动数量当作效果：只有跨任务结果和复用数据才能证明收益。
- 把凭据写进 Workspace：环境说明、权限申请和 Secret 注入必须分离。
- 绑定单一 Agent 客户端：长期资产使用通用文件与协议，客户端差异留在 Adapter。
- 混合业务状态和运行状态：需求卡片、任务现场、Session 与一次执行各自拥有生命周期。
- 把产品租户或活文档当成项目 Workspace：腾讯云工作空间、ChatGPT Space、Team Mesh 解决的是准入、共编或调度，不自动等于某一项目的 Repo 路由和验收标准。
判断建设是否有效，可以回到一个具体问题：新的 Agent Session 是否无需重复口头解释，就能找到正确事实、完成受控执行、拿出验收证据，并把经过确认的经验交给下一次任务复用。
资料来源
- 个人研发实践。访问于 2026-10-13。
- 公开产品文档，访问于 2026-09-19 至 2026-10-12：
- 程序员七七的 EI2CC Workspace：用户指出存在于私域教培内容。2026-10-12 公开检索未找到可引用原文，本文不转述其细节。
评论