企业官网建设流程全解析

为什么隔离是个记忆问题

上一篇把单会话的检索时机与注入位置排上了日程，但那些账都默认一个前提：窗口里只有你一个 Agent 的东西。一旦上多 Agent 协作——规划、调研、执行、评审各司其职——窗口这个稀缺资源立刻被多方争用，前两篇所有的预算规律全部乘以协作人数重新结算。多数团队的第一反应是"大家看同一份记录最保险"：把所有 Agent 的消息流水原样广播给每个成员。这个决定的破坏力要到协作进入第二周才显现：A Agent 把 B 早已被推翻的草稿当成现行方案复述，C 的评审意见里混进了 D 的调试日志，每个 Agent 的注意力都被别人的思维垃圾稀释，而且没人说得清是哪一步串了台。所以先把本篇的核心论点亮出来：上下文隔离不是组织信任问题，是记忆系统的写入边界问题——定义"谁能读到什么"，本质上就是在定义长期记忆的命名空间与发布流程。

三种拓扑与一条光谱

多 Agent 共享上下文有三种基本拓扑。全程共享（shared transcript）：每个 Agent 的上下文包含所有人从第一轮到上一轮的全部消息。信息覆盖率 100%，成本是平方级的——第 n 轮每个 Agent 都要重读约 n 倍的历史，四个 Agent 二十轮就是四份全量账。消息总线（message bus）：Agent 之间点对点传话，只把上一条消息交给下游。成本近似常数，但断供严重：除了紧邻上游，其他 Agent 掌握的约束与决策一律看不见，跨角色的信息通路被物理切断。黑板（blackboard）：借鉴经典分布式 AI 的黑板架构——Agent 不互读流水，而是把结论性条目（需求、约束、方案、验收标准）以压缩形式写上公共黑板，各自按订阅的键拉取相关条目。成本介于两者之间且近似线性增长，覆盖率的成败全押在"黑板上写了什么"的纪律上。三者构成一条光谱：共享越多，成本与污染越高，上下文相关性越低；共享越少，越干净但越断供。工程上没有终点站，只有按信息类型分道：定稿走黑板，工作过程留在私有区，定向请求走总线。

实验一：四种拓扑的成本-覆盖对账

下面模拟 4 个 Agent 协作 20 轮，各自有固定角色开销与订阅需求，消息体积与主题用固定种子生成，对比全程共享、消息总线、黑板、黑板+摘要四种拓扑的注入量、撞墙轮次与"需要信息覆盖率"（每个 Agent 在每轮能否读到它订阅的键）。生产系统里体积由真实组装器统计，这里用确定性模拟呈现增长形状。

importrandom rng=random.Random(492)AGENTS=["规划","调研","执行","评审"]ROUNDS=20WINDOW=9000# 每个 Agent 的上下文窗口(计量单位)BASE_ROLE=800# 各自角色设定的固定开销KEYS=["需求","约束","方案","接口","验收","里程碑"]NEED_KEYS={# 每个 Agent 真正需要的信息(订阅需求)"规划":{"需求","约束","里程碑"},"调研":{"需求"},"执行":{"方案","约束","接口"},"评审":{"方案","需求","验收"},}msgs=[]# 每轮每个 Agent 产出一条消息: (轮次, 作者, 体积, 信息键)forrinrange(ROUNDS):forainAGENTS:msgs.append((r,a,rng.randint(180,520),rng.choice(KEYS)))definject_size(topo,r,a):past=[mforminmsgsifm[0]<r]iftopo=="全程共享":returnBASE_ROLE+sum(m[2]forminpast)iftopo=="消息总线":prev=AGENTS[(AGENTS.index(a)-1)%len(AGENTS)]returnBASE_ROLE+sum(m[2]forminpastifm[1]==prevandm[0]==r-1)iftopo=="黑板":rel=[mforminpastifm[3]inNEED_KEYS[a]]returnBASE_ROLE+sum(int(m[2]*0.4)forminrel)rel=[mforminpastifm[3]inNEED_KEYS[a]]oth={m[3]forminpast}-NEED_KEYS[a]returnBASE_ROLE+sum(int(m[2]*0.4)forminrel)+60*len(oth)print("拓扑 末轮平均注入 全程累计 首次撞墙轮 需要信息覆盖率")fortopoin("全程共享","消息总线","黑板","黑板+摘要"):last=sum(inject_size(topo,ROUNDS-1,a)forainAGENTS)/len(AGENTS)total=sum(inject_size(topo,r,a)forrinrange(ROUNDS)forainAGENTS)broke=next((rforrinrange(ROUNDS)forainAGENTSifinject_size(topo,r,a)>WINDOW),None)cover=0checked=0forrinrange(4,ROUNDS):forainAGENTS:forneedinNEED_KEYS[a]:checked+=1iftopo=="消息总线":continue# 总线只传上游消息, 订阅键一律断供cover+=any(m[3]==needforminmsgsifm[0]<r)print("%-10s %10.0f %10.0f %-8s %8.1f%%"%(topo,last,total,("第%d轮"%(broke+1))ifbrokeisnotNoneelse"无",100.0*cover/checked))print("\n全程共享的注入量增长(每轮 4 个 Agent 均值, 计量单位):")forrinrange(0,ROUNDS,4):avg=sum(inject_size("全程共享",r,a)forainAGENTS)/len(AGENTS)print(" 第%2d 轮: %6.0f (窗口 %d)"%(r+1,avg,WINDOW))print("\n结论: 全量共享最先压垮最勤奋的发言者; 总线最省但断供;")print("黑板+订阅+摘要在成本与覆盖率之间取得平衡——隔离不是不信任, 而是给注意力做分账。")

运行输出：

拓扑 末轮平均注入 全程累计 首次撞墙轮 需要信息覆盖率 全程共享 28210 1103492 第8轮 100.0% 消息总线 1206 91410 无 0.0% 黑板 5588 250279 无 100.0% 黑板+摘要 5798 265219 无 100.0% 全程共享的注入量增长(每轮 4 个 Agent 均值, 计量单位): 第 1 轮: 800 (窗口 9000) 第 5 轮: 5964 (窗口 9000) 第 9 轮: 10805 (窗口 9000) 第13 轮: 17136 (窗口 9000) 第17 轮: 23594 (窗口 9000) 结论: 全量共享最先压垮最勤奋的发言者; 总线最省但断供; 黑板+订阅+摘要在成本与覆盖率之间取得平衡——隔离不是不信任, 而是给注意力做分账。

四个数字讲四件事。全程共享第 8 轮撞墙：单会话的平方级膨胀到了多 Agent 变成"每 Agent 都平方"，协作人数一多最先死的是话最多的角色——这不是调窗口能救的，是拓扑病。消息总线末轮只花 1206 单位，但覆盖率 0%：省钱的另一面是评审 Agent 从来没见过需求条目，它只能基于上游转述干活，转述质量决定一切。黑板把末轮注入压到 5588（约为全量共享的 1/5）同时覆盖率拉满，因为写上黑板的是压缩后的结论条目而非原始流水。黑板+摘要多花约 6% 的成本，给非订阅键各留一行存在性提示——当 Agent 不知道"接口"这个键存在时，它连要定向询问的机会都没有，这一行摘要就是通讯录。这与第三篇的结论同构：共享区放断言，不放过程。

该隔离什么：污染与断供的双向账

把消息流水全藏起来就安全了吗？隔离过度会付出另一种代价。下面量化三种共享粒度的两类事故率：版本污染（下游把被废弃的草稿当成现行方案复述）与依据断供（缺少"为什么这么定"的记录，被追问时重新推理出矛盾结论）。

importrandom rng=random.Random(4922)TRIALS=400MODES={# 模式: (被废弃草稿重新污染输出的概率, 因缺少依据而答错下游追问的概率)"草稿全共享":(0.28,0.02),"只共享定稿":(0.00,0.34),"定稿+决策日志":(0.03,0.06),}print("共享模式 版本污染率 依据断供率 综合失手率(独立假设)")contam_obs={}starve_obs={}formode,(pc,ps)inMODES.items():contam=sum(1for_inrange(TRIALS)ifrng.random()<pc)/TRIALS starve=sum(1for_inrange(TRIALS)ifrng.random()<ps)/TRIALS contam_obs[mode]=contam starve_obs[mode]=starve both=contam+starve-contam*starveprint("%-12s %7.3f %7.3f %7.3f"%(mode,contam,starve,both))print("\n污染的定义: 评审 Agent 的上下文里有执行 Agent 三个被推翻的草稿, 它把某个")print("被废弃版本当成现行方案重新提出——多 Agent 系统特有的'交叉污染'事故形态。")print("断供的定义: 只给定稿, 用户追问'为什么砍了方案B', 下游 Agent 无决策依据可引,")print("只能重新推理一遍, 大概率与当初结论相矛盾。")print("\n决策日志的粒度要求: 每条一行'议题|决定|理由|时间戳', 体积约为草稿的 1/20;")print("它同时压低污染与断供——这就是黑板模式存在的理由。")

运行输出：

共享模式 版本污染率 依据断供率 综合失手率(独立假设) 草稿全共享 0.305 0.022 0.321 只共享定稿 0.000 0.312 0.312 定稿+决策日志 0.020 0.065 0.084 污染的定义: 评审 Agent 的上下文里有执行 Agent 三个被推翻的草稿, 它把某个 被废弃版本当成现行方案重新提出——多 Agent 系统特有的'交叉污染'事故形态。 断供的定义: 只给定稿, 用户追问'为什么砍了方案B', 下游 Agent 无决策依据可引, 只能重新推理一遍, 大概率与当初结论相矛盾。 决策日志的粒度要求: 每条一行'议题|决定|理由|时间戳', 体积约为草稿的 1/20; 它同时压低污染与断供——这就是黑板模式存在的理由。

综合失手率从 0.321（草稿全共享）到 0.312（只共享定稿）几乎持平——两个极端各错各的：全共享错在复读废案，不共享错在无据辩护。定稿+决策日志把两率同时压到个位数，失手率 0.084，比任一极端好近四倍。这个"一行日志换双向安全"的结构正是经典黑板架构在 LLM 时代重新流行的原因：ChatDev、MetaGPT 这类框架里 Agent 间传递的不是聊天流水而是阶段产物加评审意见，本质上都是同一张黑板。

工程落地：三个平面各管一段

私有平面：每个 Agent 的工作草稿、工具回显、中间推理只进自己家，会话内滚存、跨会话按第三篇的写入路径归档，永不广播。黑板平面：只放结论性条目，写入即发布——格式统一为键+值+出处+版本，写新条目必须作废旧条目（沿用第三篇的"关闭旧区间+追加新区间"），订阅方按键拉取，拉取时叠加时近打分。总线平面：定向请求-响应，"把接口文档的超时约定发我一份"这类一次性查询走这里，响应结果若被确认为长期有效，由接收方提请上黑板，而不是留在私聊里发霉。三个平面再加一条总纪律：没有任何信息可以同时出现在两个平面——定稿上了黑板，草稿就该从可检索区退场，重复是污染的温床。预算层面，给每个 Agent 的注入配额先扣除私有工作集，剩余再分给黑板订阅，黑板订阅按键限额而不是全局 top-k，防止某一热点键吸干所有 Agent 的窗口。

常见陷阱

一是广播成瘾：所有消息进所有窗口，美其名曰"信息透明"，第 8 轮撞墙、撞完墙开始截断，截掉的恰恰是各 Agent 自己的角色设定。二是黑板当聊天室：把未定稿的讨论原样贴上黑板，污染率瞬间回到草稿全共享的水平，还多了一份"权威感"包装。三是私有区无出口：一切不上黑板、全走点对点私聊，系统里出现只有"调研 Agent 知道需求变了"的孤儿知识，其他 Agent 集体拿着旧约束干活。四是订阅无表：每个 Agent 拉"所有看起来相关"的条目，等价于软性全共享，成本曲线重新变弯。五是缺存在性提示：Agent 不知道黑板上有哪些键，连定向询问都不知道该问谁，断供被误诊为"模型能力不行"。

落地清单

• 定义信息分级：草稿/工具回显进私有区，定稿与决策日志上黑板，一次性查询走总线
• 黑板条目四要素：键、值、出处轮次、版本号；更新即作废旧版，读方永远只认有效版
• 每 Agent 注入配额两层分配：先保私有工作集，剩余按订阅键限额拉黑板，禁全局 top-k
• 键目录（存在性提示）常驻每个 Agent 头部，60 单位一行也值得
• 排障工具链支持"这条输出引用了哪个平面的哪条条目"，交叉污染事故要能 5 分钟内定位到写入者

隔离做完了，还有一个大户没进账本：工具定义。几十个工具的 schema 静态摊进每个 Agent 的窗口，是仅次于对话历史的第二吞噬者，而且它连"摘要"的资格都没有。下一篇《AI Agent 记忆与上下文工程实战（6）：工具定义的生命周期：大量工具的裁剪与动态注入》把这块固定开销变成可调度资源。

参考来源

• Wikipedia, Blackboard (artificial intelligence)：https://en.wikipedia.org/wiki/Blackboard_(artificial_intelligence)
• Wikipedia, Message bus：https://en.wikipedia.org/wiki/Message_bus
• Qian et al., ChatDev: Communicative Agents for Software Development：https://arxiv.org/abs/2307.07924
• Hong et al., MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework：https://arxiv.org/abs/2308.00352
• Anthropic Engineering, Building Effective Agents：https://www.anthropic.com/engineering/building-effective-agents