5.3 下次会议议程：框架演进方向

5.3 下次会议议程：框架演进方向

本节摘要：框架在三个方向上持续演进：任务规划（更稳的长程拆解）、记忆（更可靠的组织资产）、评估（更细的协作度量）。本节讲每个方向正在解决的具体痛点、与你使用方式的关系，以及"演进到什么程度可以调整自己的用法"的判断方法——追新要有节奏，别让框架的路线图绑架你的任务。

本节站在使用者的位置看演进：不是罗列更新日志，而是回答三个问题——5.1 列出的三大局限（轮次开销、长程漂移、评估困难），框架打算怎么补？补上之后，你现在的用法要跟着改吗？

一、方向一：任务规划——把"拆得对"从技巧变成机制

当前拆解质量（议题粒度、依赖分层）一半靠主持人模型的水平、一半靠你写议题卡的功夫。演进方向是把规划做成可校验的机制：任务树带依赖声明的标准结构、拆解结果的自检（粒度阈值、环路检测）、以及规划失败的显式上报——让"拆错了"在开工前暴露，而不是在第三轮返工时才发现。

def plan_self_check(task_tree: dict) -> dict:
    """演进方向示意：规划自检器——拆解结果先过闸再开工。
    task_tree: {'nodes': [...], 'edges': 依赖对列表}"""
    checks = {"粒度": len(task_tree["nodes"]) <= 12,
              "依赖成环": not has_cycle(task_tree["edges"]),
              "叶议题带验收": all(n.get("acceptance")
                                 for n in task_tree["nodes"]
                                 if not n.get("children"))}
    verdict = "规划通过，可以开工" if all(checks.values()) else \
              f"规划退回： {[k for k, v in checks.items() if not v]}"
    return {**checks, "结论": verdict}

def has_cycle(edges: list) -> bool:
    """依赖对成环检测（示意实现）。"""
    graph = {}
    for a, b in edges:
        graph.setdefault(a, set()).add(b)
    seen, done = set(), set()
    def dfs(u):
        seen.add(u)
        for v in graph.get(u, ()):
            if v in seen and v not in done:
                return True
            if v not in seen and dfs(v):
                return True
        done.add(u)
        return False
    return any(dfs(u) for u in list(graph) if u not in done)

# 输出：
# plan_self_check({"nodes": [{"id": "T1", "acceptance": "含币种"},
#                            {"id": "T2", "acceptance": "含基期"}],
#                  "edges": [["T1", "T2"]]})
# -> {'粒度': True, '依赖成环': False, '叶议题带验收': True, '结论': '规划通过，可以开工'}
​

对你的影响：议题卡的四要素法不会过时——机制自检替代的是"人工盯拆解"，不是"人工想拆解"。写好验收标准反而会更重要，因为自检器要拿它当闸门。

二、方向二：记忆——从个人笔记到组织资产

2.5 的三层记忆解决"单场会不遗忘"；演进方向是让记忆真正组织化：跨任务的教训按类型自动归档、团队级记忆的读写权限、以及召回的相关性排序（不让过期网页挤占桌面）。对使用者的直接变化是：纪要的写作质量从"个人美德"变成"组织收益"——2.5 的三段式写得越规范，整个委员会的召回质量越高。

def archive_lesson(lesson: dict, archive: list) -> dict:
    """演进方向示意：教训归档——按类型与适用面自动入库。
    lesson: {'内容': ..., '类型': '工具/口径/流程', '适用面': '任务/团队'}"""
    entry = {**lesson, "入库时间": "本次散会", "命中次数": 0}
    archive.append(entry)
    cross = [e for e in archive if e["适用面"] == "团队"]
    return {"本库总数": len(archive),
            "团队级条目": len(cross),
            "建议": "团队级教训纳入下期所有会议的会前召回" if cross else "暂无跨会条目"}

# 输出：
# archive_lesson({"内容": "竞品C类站点优先找第三方转述源", "类型": "工具",
#                 "适用面": "团队"}, [{"内容": "旧条目", "适用面": "任务"}])
# -> {'本库总数': 2, '团队级条目': 1, '建议': '团队级教训纳入下期所有会议的会前召回'}
​

三、方向三：评估——协作质量的可度量

评估困难（5.1 局限三）的终解是把度量做成框架能力：轮次账与 token 账自动产出、循环轮次的自动识别、产出与议题卡的自动对表。度量自动化之后，4.3 那套人工记账会逐步变成框架报表，你的精力可以从"记账"转移到"读账与改会务"。在那之前，本册教的手工记账方法依然是当前的实用解。

四、怎么追新：一条节奏建议

追新的反面教材值得记一笔：某团队每逢更新必第一时间切版本，某次升级悄悄改了工具接口的行为（冒烟用例没跑），连续三场月度会的抓取议题全部静默失败，排查花了两天。教训与 4.4 一致——每次变更后先跑冒烟与缩微会，再让正式任务上场。

⚠️ 别把框架演进当托底。规划、记忆、评估的机制化会降低出错率，但"议题卡写得烂、纪要写得糊"的损失，任何版本都替你补不回来。机制补的是下限，纪律定的是上限。

案例展开：一次按节奏追新的完整记录

背景：团队长程任务漂移明显（5.1 的对表脚本每周都在报漂移），决定跟进规划方向的新能力。操作：先核对痛点对号（确实在疼），再新旧版本各跑两场缩微会，对照发现新版的规划自检把"依赖成环"的拆解挡在了开工前——这在旧版要靠第三轮返工才暴露；随后更新团队交接文档，固化了新的配置与冒烟用例。结果：切换成本一场会，收益是长程任务的返工轮次归零。解读：这次追新成功的关键是每一步都有账可查——痛点对号、缩微对照、文档固化，节奏感来自流程而不是热情。

变式：稳定性敏感的生产环境可以采取"双轨制"——旧版本跑正式任务，新版本跑影子任务（同一议题卡、不计入交付），影子任务的账本连续两期优于正式轨再切换。慢，但没有回滚成本。

本节要点回顾

• 三个演进方向：规划（拆解自检机制化）、记忆（组织资产化）、评估（度量自动化）；
• 对你用法的影响：四要素议题卡更值钱、纪要规范变成组织收益、手工记账将逐步让位报表；
• 追新节奏：痛点对号、缩微对照、文档固化，按账本不按版本号；
• 机制补下限，纪律定上限：任何版本都替你补不了烂议题卡；
• 下一节把镜头拉远：整个多智能体领域的长期走向。