Agent工作成果如何归档复用
Agent 工作成果不应只留在聊天窗口里；团队需要把交付物、证据、过程、决策、模板和复盘分层归档，才能检索、交接和复用。
很多团队开始使用 Agent 之后，会很快遇到一个尴尬问题：任务做完了，成果却留不住。Agent 帮你查了一堆资料、跑了几轮命令、写了一个脚本、生成了一份方案、修了一个 bug、做了一次内容生产，最后只在聊天窗口里留下几屏对话。过几天想复用时，大家只能靠记忆翻找：当时用的资料在哪里？哪些命令跑过？哪个判断是人工确认的？失败过什么？下次能不能沿用那套模板？
如果没有归档，Agent 的产出就会像临时文件：当时能解决问题，之后很难复用。更有价值的不是“让 Agent 多干几次”，而是把每次任务沉淀成可检索、可追溯、可复制的工作资产。这样下一次相似任务出现时，团队不必从零开始，也不必让新人重新踩同一批坑。
归档复用不是把聊天记录全部保存下来。聊天记录太长，噪声太多，也可能夹杂敏感信息。更好的做法是把 Agent 工作拆成几层：交付物、证据、过程、决策、模板、复盘。每层保留不同粒度的信息，并给它们加上清晰的元数据。
为什么只存最终文件不够
最终文件当然要存。文章、代码、报告、图片、表格、脚本、配置、复盘文档，都是可见成果。但如果只存最终文件，团队会失去很多上下文。
第一，无法判断结果靠不靠谱。比如 Agent 写了一篇技术文章，如果没有 sources、检索词、官方文档链接和审稿记录，后来的人很难知道哪些句子有依据，哪些只是草稿阶段的推断。
第二，无法复用方法。一个成功任务背后往往有一组步骤：先查哪些来源、再排除哪些无关资料、怎么拆段落、怎么验证输出、怎么处理失败。只保存最终文件，就像只留下结果截图，没有留下操作顺序和判断依据。
第三，无法复盘错误。Agent 可能走过弯路：误读需求、工具超时、资料过期、命令失败、图片生成不稳定、输出格式不对。把这些问题删掉，短期看很干净，长期看会让团队反复遇到同类问题。
第四，无法交接。团队成员变动、项目暂停、任务转给另一条线时，只有最终文件不够。接手者还需要知道当前状态、未完成事项、风险边界和下一步动作。
归档的目标，是让未来的人能回答三个问题：这次做了什么？为什么这样做？下次怎么少走弯路？
Agent 成果至少分五层
第一层是交付物。它包括最终文章、代码、图片、表格、脚本、设计稿、配置文件、发布包等。交付物要有版本、路径、状态和负责人。
第二层是证据。证据包括来源链接、文档版本、论文、GitHub release、网页快照、测试结果、dry-run 输出、图片 manifest、审稿意见、日志片段。证据不是为了堆材料，而是为了让结论能回到来源。
第三层是过程。过程包括任务拆解、执行命令、工具调用结果、失败原因、重试方式和耗时异常。GitHub Actions 文档提到，workflow run logs 可以查看、搜索和下载；artifacts 可以在 workflow run 中上传、下载和设置保留期。这给 Agent 工作一个启发：过程材料不必永久混在正文里，但要知道哪些过程证据需要保存多久、放在哪里。
第四层是决策。比如为什么选这个方案，不选另一个方案；为什么某个图要重生成；为什么某个功能先不做；为什么某个来源不采用。决策记录要短，但要写清背景、选项、取舍和影响。
第五层是模板。每次任务里可复用的部分，要从交付物里抽出来：提示词结构、目录结构、检查清单、数据字段、发布包格式、命名规范、复审标准。模板不是复制上一份结果，而是复制下一次可执行的方法。
有些团队还会加第六层：复盘。复盘记录这次做得顺的地方、卡住的地方、下次要提前准备的东西。Google SRE 强调复盘要关注促成因素，不针对个人；Atlassian 也把复盘看成团队学习和改进的机制。Agent 工作复盘也一样，不是找谁提示词写得不好，而是让系统下次更好用。
给每个成果加元数据
没有元数据的归档，很快会变成一堆文件。最少要给每个任务留下十个字段。
1. 任务 ID：唯一标识，便于检索和引用。 2. 任务标题：一句话说明做了什么。 3. 所属项目：它属于哪个长期项目、客户或内容池。 4. 输出类型：文章、代码、研究、图片、数据、自动化、复盘等。 5. 状态：草稿、待审、已发布、已归档、已废弃。 6. 主要文件：最终交付物和证据路径。 7. 主要来源：官方文档、论文、仓库、日志、审稿意见等。 8. 复用标签：下次可按什么标签找到它。 9. 风险边界：哪些内容不能直接复用，哪些需要重新核验。 10. 下一步：是否需要审稿、发布、改稿、清理敏感信息或沉淀模板。
OpenTelemetry 的日志数据模型强调，日志需要被记录、传输、存储和解释，并能从不同来源映射到共同模型。Agent 归档不等于照搬日志规范，但思路相似：先统一字段，未来才容易搜索、聚合和迁移。
不要把所有聊天记录都当资产
聊天记录有价值，但不是所有内容都值得长期保存。长期保存之前，需要先做筛选。
应该保存的内容包括：用户目标、主要约束、最终输出、引用来源、验证命令、失败原因、人工确认、未完成事项、对后续任务有帮助的提示词结构。
应该谨慎保存的内容包括：临时口头讨论、重复试错、敏感路径、凭据片段、无关闲聊、工具输出里的私人信息、未核验猜测。保存前要做清理，把密钥、cookie、个人隐私、客户数据和不该公开的配置去掉。
可以把归档分成两种视图。
第一种是“工作视图”。它保留较多过程材料，给接手任务的人看。比如完整命令、日志路径、失败记录、输出文件和复审意见。
第二种是“知识视图”。它只保留结论、方法、证据和可复用模板，给以后检索的人看。知识视图要短，要能被标题、标签和摘要命中。
这两个视图不要混在一起。工作视图解决交接，知识视图解决复用。
归档路径要可预测
归档能不能复用，很大程度取决于路径是否稳定。路径不要只按日期堆，也不要只按文件类型堆。更好的结构是“项目 / 任务 / 产物类型”。
例如：
- project-hub：项目目标、范围、状态、负责人。
- tasks：每次 Agent 任务的任务卡。
- outputs：最终交付物。
- evidence：来源、日志、测试结果、dry-run、manifest。
- decisions：决策记录。
- templates：从任务里提取出来的可复用模板。
- reviews：人工或模型复审意见。
- retrospectives：阶段复盘。
如果是内容生产，每篇文章可以有固定包结构：正文、HTML、来源、图片提示词、图片 manifest、发布包、README、复审记录。固定结构会让审发、搜索、迁移和自动校验都简单很多。
路径稳定以后，Agent 也能更容易接手。它不需要每次问“文件放哪”，只要按约定读取任务包，就能知道哪些是正文、哪些是证据、哪些是待办。
从成果里提取模板
复用不是复制成品，而是复制结构。一个 Agent 任务完成后，可以问四个问题。
第一，这次有哪些步骤以后还会重复？比如“先调上下文接口、再查官方资料、再写正文、再生成图片、再 dry-run、再写回项目记录”。
第二，这次有哪些检查项以后还会重复？比如“正文是否超过 3000 字、来源是否可信、图片是否真实生成、manifest 是否显示 b64_json、dry-run 是否 published=false”。
第三，这次有哪些提示词结构以后还会重复？比如图片提示词里的标题、布局、色彩、禁用项；研究提示词里的读者、来源、风险边界。
第四，这次有哪些坑以后要提前避开？比如上游生图服务慢、某类图容易生成虚构数字、某些词容易触发审计、某些状态不能标记通过。
把这些东西抽出来，就会得到模板。模板可以是一份 Markdown，也可以是一段 JSON schema，一张检查清单，或者一个脚本参数示例。它不需要很长，只要能让下一个任务少问几个问题、少犯几个错误。
检索要围绕问题，而不是围绕文件名
团队检索归档时，很少会记得精确文件名。大家会问的是：
- 上次类似任务怎么做？
- 哪个模板可以复用？
- 这个来源以前用过吗？
- 哪些图生成时容易出问题？
- 某个发布流程的 dry-run 证据在哪里？
- 这个项目上次停在什么状态？
所以，归档系统要支持问题式检索。文件名当然重要，但标签、摘要、任务 ID、来源 URL、状态、风险边界同样重要。
一个可用的检索记录可以这样写：
任务：为某平台生成一篇技术科普文章。
可复用部分：文章包结构、来源记录格式、图片提示词结构、dry-run 检查命令。
不能直接复用的部分：具体事实、价格、发布日期、模型能力、平台规则。
下次搜索词：技术科普、图片 manifest、dry-run、发布包、复审 pending。
这样的记录比“某某文章最终版”有用得多。它告诉未来的人，哪些东西能拿来用，哪些东西必须重新查。
复盘要变成下一次的输入
复盘不是任务结束后的仪式。它应该变成下一次任务的输入。
一次 Agent 工作复盘可以很短，只写六项：
1. 目标：这次要完成什么。 2. 输出：最后产出了哪些文件或结果。 3. 证据：哪些来源、日志、测试或 dry-run 支撑了结果。 4. 卡点：哪里慢、哪里失败、哪里需要人工判断。 5. 改进：下次要提前准备什么。 6. 模板：有哪些步骤、字段或提示词可以抽出来复用。
Google SRE 的复盘文化强调从促成因素中学习；Atlassian 也提醒团队先建立开放、事实导向的讨论氛围。Agent 工作复盘同样要避免把问题写成“某人没提示好”，而要写成“缺少输入字段”“来源不够清楚”“没有提前定义检查标准”“图片提示词需要限制虚构数字”。
当复盘能进入下一次任务，归档就不再是仓库里的灰尘，而是任务启动时的燃料。
一个可执行的归档动作
如果团队刚开始，可以用一个很小的动作启动：每次 Agent 完成任务后，强制写一份 README。
README 里只放八项：
1. 当前状态。 2. 交付物路径。 3. 证据路径。 4. 验证结果。 5. 复审状态。 6. 风险边界。 7. 下一步。 8. 可复用模板。
再进一步，可以把 README 同步到项目 Hub，把来源和测试结果放进 evidence，把模板放进 templates，把阶段性经验写进复盘。这样每个任务包都能独立交接，也能被汇总到项目级知识库。
Agent 工作的价值，不只在它这次帮你做完了什么，还在它让下一次任务更容易开始。归档复用做得好，团队会慢慢拥有自己的任务记忆：知道哪些方法有效，哪些来源可靠，哪些坑要避开，哪些模板可以直接拿来改。
这才是 Agent 从“临时帮手”变成“团队工作系统”的重要一步。