AI工程SynapseB类

用 Agent 记忆协作机制把 L1-L2 决策交还机器：Lysander 组织的分级实践

当 AI 组织能够自主路由任务、调用历史归档、跨 Agent 协作时，人类只需在 L4 知会、L5 裁决两个节点介入而非参与每一步

  • 上下文外置化：product-profile替代人工逐字交接
  • 30秒恢复：active_tasks.yaml实现跨会话状态续接
  • L1-L2 区间由路由规则自动分流，节省总裁早间确认 17 条/天；具体百分比受任务结构波动，未做严格统计。
  • 断点定位：active_wbs字段将恢复时间从5分钟压缩至秒级

问题背景

在 Synapse 体系运行第三周时，我发现每天早上总裁需要处理大量任务确认请求——几乎每个产品线的协调节点都在等他确认"这个决定是否在授权范围内"。一个具体的数字是：最高峰时，晨会开始前有 17 条待确认消息堆积在协作频道。这种"审批即瓶颈"的状况与引入 Agent 协作的初衷相悖——我们希望机器承担重复决策，而非让人类成为单点阻塞。

根本矛盾在于：多 Agent 协作时，每个 Agent 需要知道"任务背景是什么""当前卡在哪里""下一步谁接手"，但 LLM 本身是无状态的。没有外置记忆机制，Agent 每次对话都从零开始，要么依赖人工反复说明背景（效率低下且容易遗漏），要么做出超出授权范围的决策（风险不可控）。

为什么这个问题比想象中更难

我们一开始以为解决状态共享问题很简单：给每个 Agent 配一份产品背景文档，让它读取即可。但在实际运行中，product-profile.md 最初只记录静态的产品描述——功能特性、技术栈、团队联系人。结果我们一开始以为"Agent 能读懂产品背景就够了"，但实际上，它能回忆背景却无法定位上次执行断点。

具体表现是这样的：Lysander 早晨恢复任务时，发现 active_tasks.yaml 中有 12 个进行中的任务，每个任务都有当前的 blocker 和 next_step。但要从 product-profile.md 关联到具体任务，需要逐条扫描所有任务的上下文字段来判断"这条任务属于哪个产品线"。一次完整的恢复扫描需要接近 5 分钟，而实际操作中很多任务的 blocker 只需要 30 秒就能处理。

这个问题的本质是：上下文注入（让 Agent 知道"是什么"）和状态追踪（让 Agent 知道"做到哪了"）是两件不同的事。product-profile 提供前者，但缺少后者所需的直接定位能力。

根因分析与核心设计决策

根因是在 product-profile.md 的 frontmatter 中缺少一个关键字段：当前活跃任务与文件的直接关联。

修复方案是在 frontmatter 中增加 active_wbs 字段，记录该产品线下当前进行中的任务编号列表。这使得每次会话开始时，Lysander 可以在 30 秒内完成恢复：读取 agent-CEO/config/active_tasks.yaml 获取完整任务图谱，然后对每个任务直接定位到对应的 product-profile，无需全量扫描。

# obs/02-product-knowledge/PMO-Auto-Monday/product-profile.md
---
product_name: PMO自动化工具链
version: "2.3"
active_wbs:
  - WBS-2024-0892
  - WBS-2024-0911
last_synced: "2024-01-15T09:30:00+08:00"
---

## 产品背景

PMO自动化工具链负责协调跨团队的周报汇总、里程碑对齐和风险预警。当前版本实现了基于自然语言的周报解析，识别关键阻塞并生成升级建议。

## 活跃任务摘要

**WBS-2024-0892**：多语言周报格式标准化，本周完成 EN/JP/FR 三种模板的 schema 定义，阻塞原因是韩语模板的依赖库版本冲突。
**WBS-2024-0911**：历史周报检索优化，目标将搜索延迟从 3.2s 降至 800ms 以内，已完成索引重构，待上线灰度验证。

配合这一改动，.claude/harness/product-routing.md 中的路由规则在派单时自动注入对应 product-profile 的全文，约 300-400 字的上下文注入替代了原本需要协调员逐字说明的产品背景交接。

决策授权的自治同样依赖这套机制。CLAUDE.md 中定义的 L1-L4 四级决策体系：L1 由系统自动执行、L2 经智囊团评审、L3 由 Lysander 决策、只有 L4（合同法律、100 万以上预算、公司存续级决策）才上报总裁。实际运行数据是约 85% 的任务落在 L1-L2 区间，全程自主完成。

如果你的 Agent 协作体系出现"人工审批成为瓶颈"，先检查的是状态恢复路径——能否在秒级而非分钟级完成跨会话断点定位，而不是直接增加授权范围。

可移植的原则

  1. 如果你在设计多 Agent 协作的记忆机制，将"任务当前状态"（active_wbs这类）与"背景信息"（静态描述）分离存储，前者高频更新、后者相对稳定，避免将动态字段混入静态文档导致版本管理混乱。
  2. 如果你在评估 Agent 的状态恢复效率，用"从零到可用"的时间来度量而非"处理单条任务的时间"，瓶颈往往在上下文加载而非推理。
  3. 如果你在设计决策授权体系，从 L1 开始逐级定义，并在每次任务交接时显式标注"这个决策落在哪一级"，而不是默认所有决策都需要人工确认。
  4. 如果你在优化跨 Agent 信息传递，用"注入上下文的长度"作为效率指标——300-400字的定向注入远优于让 Agent 反复询问"这是什么产品线"。

结尾

当你发现 Agent 协作体系中存在频繁的人工确认请求时，症结往往不在授权粒度太细，而是状态恢复路径太长。检查 active_tasks.yaml 的写入机制是否强制执行、product-profile 的 frontmatter 是否包含直接定位字段——这两处改动可以将早晨的恢复时间从分钟级压缩到秒级，让 Agent 在你到达工位前已经进入工作状态。