Career Coach 是一个围绕长期求职准备搭建的 Agent 协作系统原型。它基于本地 Markdown 文件和 coding agent（Claude Code、Codex 等）工作流运行，处理一类具体问题：当一项任务持续数周到数月、涉及多类材料和多轮讨论时，Agent 如何稳定地接续状态、组织上下文、校准目标，并把每一轮的判断沉淀成下一步可以使用的结构。
虽然项目本身用于求职准备，要解决的是更普遍的一类任务——高上下文、长周期、需要多轮推进，且每一轮都依赖之前的积累。这类任务在写作、研究、产品分析、长期项目管理中都常见。Career Coach 是其中一个具体形态的尝试，在个人场景跑了几个月，结构在使用中逐渐稳定下来。
为什么普通 chatbot 难以接住长期任务
一个常见场景是：上周你在某个 chatbot 里和 AI 认真讨论过一个项目方案，今天想接着推进。
打开新对话后，第一步往往不是提问，而是先解释背景：你是谁、之前做过什么、上次否掉了哪些方案、现在要继续聊哪一块。讲完背景，又想起旧对话里几段关键判断需要搬过来，于是去历史列表搜对话标题、滑滚轮上下翻动、复制粘贴，再手动加上”以下是背景、以下是上次结论、以下是这次任务”的分隔线。也可以让 AI 在旧对话末尾生成一份交接文档，但经常太精炼，要再人工核对细节。
等这些都做完，任务还没真正开始，人自身的注意力已经被消耗了一轮。
有的情况更难处理：一些过去讨论过的判断本来已经定下，在新的对话里被 AI 顺着当下的问题重新拐了方向；或者旧对话越聊越长，重要结论沉在中间，连自己都翻不出来。
问题落在长任务里的”接续”上：状态不清楚、上下文不分类、关键判断难以复用。
系统如何组织长期协作
可以把 Career Coach 想成一个”长期任务的工作台 + 状态面”。
每次新会话开始时，Agent 先看一眼状态面（现在停在哪里、下一步是什么），再有针对性地翻工作台上对应的几份材料（这次要用什么），讨论结束后把真正影响下一步的结论写回对应位置。日常档案、历史讨论、当前判断、外部资料各自归位，每一类不和别的混在一起。
这套结构关心两件事：每次会话都能从一个清楚的当前状态出发；讨论完之后留下一些下次还能用的东西。如何让 Agent 记得更多东西——反而不是重点。
实际运行中也观察到：用户已有的备忘录、侧边栏笔记 App、收藏夹相关的记录习惯，并不会因为有了这个系统就消失。临时灵感、半成型的想法仍然会先出现在那些更轻更便捷的工具里。一个更现实的产品化方向，是在”正式计划、临时想法、外部资料”之间建立连接，是原有工具和系统形成接力，而不是要求用户把所有信息都搬进这个系统。
核心模块
career-coach-agent/
├── COACH.md # 系统入口，定义协作规则
├── coach_system/ # 启动、开场、运行、归档流程
├── DASHBOARD.md # 状态看板：当前阶段、最近进展、下一步
├── profile.md # 稳定档案：背景、经历、偏好、长期约束
├── control_plane/
│ ├── CURRENT_STRATEGY.md # 当前阶段战略判断
│ └── CURRENT_PLAN.md # 当前计划和下一步行动
├── session_log/ # 历史会话归档
├── resources/ # 外部资料、草稿、调研、写作材料
└── CHANGELOG.md # 系统迭代记录COACH.md 是入口，定义协作规则；coach_system/ 放具体的启动、开场、运行、归档流程文件。两者分开，是为了让”系统是什么”和”系统怎么跑”各自可读、可改。
状态看板
DASHBOARD.md 是新会话的入口。聊天式 Agent 的界面通常只有一个空白输入框，用户容易忘记上一轮做到哪里，也容易忘记系统能帮自己做哪些事。状态看板相当于一个轻量 UI：包含当前阶段、最近进展、下一步动作，让人和 Agent 都能在第一秒回到同一个位置。
上下文路由
这不是一种通用记忆架构，只是这个原型在实际使用中、从摩擦里逐渐归出来的四种上下文分类。每一类对应一个具体问题：
| 上下文类型 | 主要内容 | 解决的问题 |
|---|---|---|
| 稳定的背景信息 | 长期有效的个人经历、偏好、约束 | 每次新会话，用户不用重新解释自己 |
| 历史归档 | 过去的重要讨论和阶段性结论 | 旧讨论能留存下来，又不会反复跳出来干扰当前对话 |
| 当前判断 | 本阶段仍然有效的策略和计划 | 默认会进入每一轮的讨论，避免 Agent 忘记用户的核心目标 |
| 外部资料 | 行业文章、产品笔记、用户反馈、写作素材等 | 按本轮任务有选择地接入，不污染主上下文 |
每次会话需要的，不是”全部上下文”，而是”这一轮要用的那部分”。
阶段性计划
CURRENT_PLAN.md 和 CURRENT_STRATEGY.md 保留当前仍然有效的判断。它和 session log （历史归档）的差别在于：session log （历史归档）记录的是过程，内容可以允许发散、可以是流水账；而 plan 和 strategy 记录的则是结论，留存住结论，Agent 才能知道什么是该过滤掉的噪音。Agent 接手任务时优先读这两份文件，避免每次都从历史流水账里反推现在该做什么。
外部资料接入
外部资料进入系统时通常先做一次人工筛选，再交给 Agent 阅读和复述。这一步的目的是让新信息落到下一步行动上。一份行业文章、一段用户反馈、一次竞品体验，如果只是被保存下来，仍然停留在素材层；改变了下一步行动、产品判断或对外交付物的，才真正进入了系统。
目标校准
开放式写作、定位讨论、策略调整这类任务容易出错。Agent 会延续旧共识、输出看似完整但不契合真实读者需求的内容、顺着临时想法发散、把内部讨论语言直接当成对外产出。
所以在这类任务前，会先做一轮校准：这次产物给谁看、要解决什么问题、哪些内容不能写、是否需要参考外部样本和例子。校准的作用是，用现实约束把 Agent 从已有的上下文的自我循环里拉出来。
写回机制
讨论结束后，只把真正影响后续行动的结论写回 plan、strategy 或 session log；一次性的解释和发散内容留在对话里就好。这一步容易被忽略，但它决定了下一次新开对话窗时，Agent 拿到的是”已经整理过的材料”，还是”一摞没整理的对话”。
人和 Agent 的分工
Agent 承担执行性脑力工作：阅读资料、提取关键信息、比较多个材料或方案、整理上下文、改写草稿、提出结构和下一步建议；它也承担一部分辅助判断，比如指出冲突、提出风险、列出方案的取舍。
人承担方向性判断：哪些资料值得进入系统、哪个方向更值得推进、某个表述是否符合当前定位、Agent 的建议是否采纳、哪些结论应该写回。
整体上，Agent 的目标是把材料、路径和选项整理到一个更容易判断的状态，这些判断最终仍然需要人来审阅、由人来做决定。系统的最终输出，取决于使用它的那个人的判断力。
可迁移的产品方向
Career Coach 来自一个具体任务，其中几块结构在其他高上下文、长周期场景里也会反复遇到：
| 结构组块 | 解决的问题 | 可能适合的场景 |
|---|---|---|
| 状态接续 | 用户下一次回到任务时，怎么在很短时间内记起”上次做到哪里了” | 个人 AI 工作台、办公助手、研究助手 |
| 上下文路由 | Agent 怎么区分长期背景、历史材料、当前判断、外部资料，避免一锅炖、上下文污染 | 知识库类产品、AI 工作台、长期写作 / 研究助手 |
| 资料接入 | 新读到的内容怎么影响下一步行动，而不是只被收藏 | 个人知识服务、内容工作流、竞品 / 行业研究 |
| 目标校准 | 在开放式任务前，怎么先明确读者、目标、约束、可接受的样例 | 写作 Agent、vibe coding、设计 / 方案协作 |
| 写回机制 | 怎么让每次讨论都留下下次直接能用的状态文档 | 长期协作 Agent、企业内部助手、项目管理 |
| 与用户已有工具共存 | 怎么和备忘录、文档、IM 软件、浏览器收藏夹等真实工作习惯连接 | 想成为工作入口的 Agent 产品 |
这些结构组块指向一个底层问题：当 Agent 试图成为长期任务的协作层时，它需要能恢复状态、筛选上下文、推动下一步、把关键结论留住。这件事在不同形态的产品里会有不同的实现路径。
进一步的产品化方向
在原型之后，比文件结构本身更值得沉淀下来的，是几个显式化的环节：状态接续、上下文路由、目标校准、写回。这些环节指向了进一步的产品化方向——重点不应只是让系统记住更多内容。更自然的产品化方向，会在于这几个能力：
- 更低成本的状态恢复：用户回来时立刻知道任务停在哪里。
- 更清晰的上下文选择：帮用户决定当前任务应该激活哪些材料。
- 更自然的外部资料接入：让文章、反馈、竞品体验进入后续行动，而不只是停留在收藏夹。
- 更可靠的目标校准：在开放式生成前，先明确读者、约束和验收标准。
- 更轻的写回方式：让关键结论自然沉淀到下一轮任务里，而不是要求用户每次手动整理完整归档。
原型规模不大，但运行过程中，长期 Agent 协作里的几个具体问题已然浮现：状态、上下文、目标、判断、写回，以及如何和用户原有工作习惯共存。若面向更多用户或更具体的业务场景，这些问题也值得继续被拆开验证。