Buzz 的 Agent 活动流Activity Feed设计以「动词-对象-结果」为骨架构建可监督、可信任的代理协作界面【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读本文将系统拆解 BuzzA hive mind communication platform中「Agent Activity Feed」这一核心功能的设计愿景与落地实现。它解决的是所有代理协作场景的共同痛点当你把工作委托给一个 Agent 时你信任的是一个看不见的过程——活动流就是通向这个过程的窗口。读完本文你将掌握活动流如何用「动词-对象-结果」三要素将原始事件流转化为一眼可读的监督界面十二种渲染分类render class如何划分信息的阅读频率与后果权重以及该设计在桌面端代码中如何以分类器、分组器与渲染器三层管线实现。文中所有实现细节均以当前仓库源码与测试为依据可对照验证。一、问题背景为什么原始 IO 转储不是窗口When you delegate work to an agent, you are trusting a process you cannot see. The activity feed is the window into that process — but a window is only useful if you can read it at a glance.把工作委托给 Agent本质是信任一个不可见的过程。活动流是这个过程的窗口但窗口只有在可以一眼读懂时才有价值。原始输入/输出转储raw input/output dump不是窗口而是需要解码的转录稿transcript——它强迫你先parse解析再judge判断这在监督场景中是致命的延迟。该愿景在 VISION_ACTIVITY.md 中给出的目标是让开发者像监督一名得力队友一样监督代理——扫一眼看进度、信任常规操作、只捕捉需要自己的那一件事而不必逐行阅读。这个理念在桌面端代码中体现为对「原始事件」与「语义卡片」的刻意分层原始 ACP 帧raw_json_rpc会被归入 metadata 噪声门正常叙事流中不渲染只有按需进入 raw rail见下文。从源码结构看桌面端由ObserverEventagentSessionTypes.ts承载来自 relay 的原始事件再由转录构建管线转换成语义化条目。二、服务对象与三大问题理解、信心、控制活动流服务于监督委托方的开发者。他不是为了娱乐而观看而是在决定是否介入。因此feed 中的每一项都必须通过回答以下三个问题来赢得它占据的像素Comprehension理解—— 它在做什么为什么Confidence信心—— 进展顺利还是卡住或出错了Control控制—— 我需要介入吗从哪里介入能即时回答这三个问题的 feed能把事件流转化为轨迹感trajectory回答不了的 feed只是带滚动条的噪声noise with a scrollbar。在实现层AgentActivityToneread | write | admin | neutral见 agentSessionTypes.ts正是为回答「信心/控制」问题而设计的维度写操作与管理操作被赋予更响亮的呈现读操作则安静地退居次席。三、统摄框架动词-对象-结果Verb, Object, Outcome活动流中每个有意义的条目都是一句话agent 对 [对象] 做了 [动词] → [结果]。Sent a message to #design. · Editedruntime.rs(12/−3). · Reacted to Marges review. · Ran tests → 1248 passed.feed 的职责是第一时间呈现动词、对象、结果并把支撑细节——完整参数、原始输出、完整 diff——推入渐进式披露progressive disclosure。你读句子只有句子让你想看时才展开。这一框架在代码中有直接对应物AgentActivityAction类型{ verb: string; object?: string | null }见 agentSessionTypes.ts与AgentActivityDescriptor中的label、preview、action、object字段。而分类器负责从工具调用中提取动词buzzOperationVerb把操作映射为规范动词add→Added、create→Created、delete→Deleted、get/list/members→Read、send→Sent、search→Searched等agentSessionToolClassifier.tsbuzzOperationObject把操作名还原为可读对象如messages→ message从而拼出 Sent message to #design 这类句子同文件 L433-L444。四、十二种渲染分类Render Classes完整的事件分类学每个事件最终都解析为十二种呈现类别之一按被阅读的频率与承载后果的大小组织4.1 脊柱层The spine—— 常读常新类别含义MessageAgent 的声音对外发言Buzz relay op在平台上的实际操作File-edit真正的代码工作Shell commandAgent 的双手Tool status turn lifecycle心跳回合生命周期如果这五类不清楚feed 就是失败的。4.2 高价值上下文High-value context—— 用于判断正确性类别含义Thought推理过程随取随用Plan/Todo路线图与进度条Permission控制闸门Error停止标志4.3 环境安全网Ambient safety net—— 很少读但必须存在类别含义Generic tool诚实的兜底呈现Raw rail按需取用的地面真相ground truthSuppressed noise我们刻意不渲染的内容关键论断这不是愿望清单而是完整的分类学——Agent 能发出的每个事件恰好落入其中一个类别而最后三类保证了永远存在「地板」。代码侧完全印证了这一「穷尽性」承诺AgentActivityRenderClass在 agentSessionTypes.ts 中定义为 15 个值的联合类型message、relay-op、file-edit、file-read、skill-read、image、shell、status、thought、plan、permission、error、generic、raw-rail、suppressed——其中读类在实现中被细分为 file-read / skill-read / image 三类对应文档十二类的读操作家族而路由表 TranscriptActivityItem.tsx 用satisfies RecordAgentActivityRenderClass, ActivityRenderClassPresenter声明了从每个渲染类到呈现组件的穷尽映射——TypeScript 会在新增渲染类时强制补齐对应组件从编译期保证了「每个事件都有归属」。五、九条设计原则与源码印证5.1 语义优先于传输Semantics over transport渲染agent 做了什么而不是它用了哪个 API。通过 MCP 工具发送的消息与通过 shellbuzz命令发送的消息渲染为完全相同的卡片。Agent 如何到达 relay 是管道细节做了什么才是契约。代码印证AgentActivityDescriptor.sourcemcp | shell | acp | harness | fallback只用于调试标注不决定渲染类别。分类器classifyBuzzTool与parseBuzzCliCommand殊途同归——前者识别 MCP 工具名如send_message后者解析 shell 命令 token如buzz messages send ...两者都产出renderClass: messageagentSessionToolClassifier.ts证明「同一语义、同一卡片」在实现层成立。5.2 结果优先Outcome-first以成功、失败或结果开头。读者在一秒内决定是否展开。原始转储是兜底绝不是标题。代码印证classifyTool在识别出语义类别后一旦isError为真立即把渲染类升级为error并给标签追加 failedagentSessionToolClassifier.ts——失败永远占据最响亮的呈现位置。5.3 原地更新Mutate in place正在执行的动作在其自身行内从 pending → executing → done/failed 更新。一个动作就是一个条目而不是一串重复的状态行副本。代码印证ToolStatus executing | completed | failed | pendingagentSessionTypes.ts与TranscriptItem的startedAt/completedAt字段均为单条目多状态模型服务。5.4 永不失明Never go dark事件的缺席本身也是信息。Silence、idle、timeout 是被渲染的状态——waiting…、timed out——而不是空洞。这镜像了项目对 Agent 的规则如果你没展示它它就没发生if you didnt show it, it didnt happen。5.5 失败上扬、阅读退后Failures rise; reads recede显著性salience跟随后果。管理操作、写入、错误是响亮的读取和推理是安静的。被埋没的错误就是坏掉的 feed。代码印证AgentActivityTone的 read/write/admin 三分法直接驱动显著性buzzCliTone依据动词组判定音调BUZZ_CLI_ADMIN_VERBS→ admin、BUZZ_CLI_READ_VERBS→ read见 agentSessionToolClassifier.ts 与 L446-L451。5.6 解析引用Resolve references展示 #design、Marges message、文件名——绝不是一个原始 event id 或 pubkey。读者用名字思考不用哈希。5.7 合并流Coalesce streams分块的文本合并为一个条目。开发者读的是消息不是包追踪packet trace。代码印证这是实现中最精细的部分之一。agentSessionTranscriptGrouping.ts 实现两遍工具分组第一遍same-kind把同groupKey的连续运行折叠成带具体标签的摘要——Read 3 files、Edited 2 files、Ran 4 commandssameKindLabelL365-L380第二遍mixed burst把不同种类交错的常规工具工作折叠成 Ran N tool calls 摘要并且容忍交错search → read-summary → search → read-summary 可合并为一行监督记录关键边界消息、权限、错误/失败工具、status/suppressed 行永不参与分组且会打断 run——保证介入点始终可见isGroupingEligibleL351-L357。这与 5.5「错误不能被埋没」互为表里。5.8 诚实胜过猜测Honesty over guessing被识别的操作得到语义卡片未被识别的则降级为干净、真实、通用的行。绝不为了显得更丰富而编造语义。代码印证分类器按「load_skill → developer harness tool → buzz tool」三级providers链尝试agentSessionToolClassifier.ts全部未命中时落入genericDescriptor渲染类为generic、label 为 Ran tool、source 标记为fallback——诚实兜底被显式建模。5.9 默认打磨、按需原始Polished by default, raw on demand策展curation是产品本身raw rail 是安全网。二者之间的切换是同一真相的不同缩放级别而不是两个不同的 feed。代码印证RawRailActivity组件把 metadata 条目渲染为可折叠的 section 列表raw_json_rpc原始负载默认收进details折叠区点击才展开pre原始文本RawRailActivity.tsx同时该渲染类的专属渲染测试覆盖了原始载荷路径RawRailActivity.render.test.mjs。六、噪声门与「脊柱」识别让信号可读的隐藏机制「决定不显示什么」与「决定显示什么」同样重要。实现中有两层噪声治理噪声门noise gateisMeaningfulItem过滤掉被抑制的工具行renderClass suppressed、生命周期噪声turn started、session ready、wire parse error以及原始 JSON-RPC 帧raw_json_rpc见 agentSessionTranscriptPresentation.ts脊柱识别spine detectionisSpineItem判定哪些条目是「脊柱工作」工具、消息、思考、计划、有意义的生命周期事件metadata系统提示、提示上下文属于应退后的阅读类BotActivityBar 用它做两档标题扫描——先收集脊柱标题找不到时再回退包含 metadata避免会话开始/空闲时栏为空L86-L100。SuppressedActivity渲染器则负责把「刻意不渲染」的内容以最小化行呈现只显示动词-对象与耗时SuppressedActivity.tsx。典型例子是开发 harness 的stop_hookChecked todos——它是心跳级动作展示语义但占据最少像素agentSessionToolClassifier.ts。七、会话边界与回合组织长时监督的秩序感feed 需要处理多会话、多回合的长时运行。buildTranscriptDisplayBlocks负责把扁平、按时间排序的条目流组织成展示块agentSessionTranscriptGrouping.ts会话边界session-boundary当条目跨越多个会话归档历史 实时会话时在连续会话运行之间注入分隔块并区分三种标签状态current最新可见且匹配 relay 实时会话、most-recent最新可见但会话已结束、earlier更早的会话——让「当前上下文」与「历史」永远清晰回合分组turn bucket同一turnId的条目聚合为一个回合块回合内再细分 prompt用户提示 上下文 setup 生命周期、活动段与摘要段边界键稳定性会话边界块的 React key 使用firstItemId对前置插入稳定而非runIndex避免归档页加载更早会话时引起边界节点不必要的重挂载L754-L764。这些机制共同构成「永不丢失」的保证restart 时session/new标记会暂时驻留缓冲直到新会话解析后重新锚定流在重启中途结束时则把缓冲刷回当前会话——任何条目都不会被静默丢弃。八、这一设计换来了什么赢得委托Earning Delegation活动流真正的工作是赢得委托earn delegation。可见的进度、可见的同意、可见的结果是复合增长的每一次你看到回合顺利进行的观察都让你更信任 agent 去承担更大的回合。决定不显示什么——抑制心跳与内部闲谈——与决定显示什么一样是功能因为抑制正是让信号可读的原因。这一 feed 在基础上是协议诚实protocol-honest的任何符合规范的 agent 的消息、思考、工具调用、回合都会成为一等公民条目无论它运行的是什么工具。而 Buzz 专属的丰富层——语义 relay 卡片、buzz-CLI 解析器、diff 渲染——是其上的一层增强而非其下的硬性要求。非 Buzz 代理获得正确、可读的 feedBuzz 代理获得原生native的 feed。同一真相的两个高度打磨版供判断原始版供调试。窗口始终是窗口。这句话在代码中的落点是TranscriptActivityItem用一张穷尽的路由表在同一个 DOM 流里渲染所有呈现类TranscriptActivityItem.tsx而RawRailActivity在同一流中以折叠姿态存在——两者不是两个 feed而是同一个真相的两种缩放。九、延伸阅读愿景文档VISION_ACTIVITY.md渲染类路由与穷尽映射desktop/src/features/agents/ui/activityRenderClasses/TranscriptActivityItem.tsx类型定义渲染类、音调、动作、条目联合类型desktop/src/features/agents/ui/agentSessionTypes.ts工具分类器Buzz MCP 工具 / buzz CLI 解析 / 兜底desktop/src/features/agents/ui/agentSessionToolClassifier.ts流合并与两遍分组、会话边界desktop/src/features/agents/ui/agentSessionTranscriptGrouping.ts标题生成与噪声门desktop/src/features/agents/ui/agentSessionTranscriptPresentation.ts十二类呈现组件目录desktop/src/features/agents/ui/activityRenderClasses/相关测试渲染路由与分组行为见 agentSessionTranscriptGrouping.test.mjs、agentSessionTranscriptPresentation.test.mjs、RawRailActivity.render.test.mjs【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buzz 的 Agent 活动流（Activity Feed）设计：以「动词-对象-结果」为骨架构建可监督、可信任的代理协作界面
Buzz 的 Agent 活动流Activity Feed设计以「动词-对象-结果」为骨架构建可监督、可信任的代理协作界面【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读本文将系统拆解 BuzzA hive mind communication platform中「Agent Activity Feed」这一核心功能的设计愿景与落地实现。它解决的是所有代理协作场景的共同痛点当你把工作委托给一个 Agent 时你信任的是一个看不见的过程——活动流就是通向这个过程的窗口。读完本文你将掌握活动流如何用「动词-对象-结果」三要素将原始事件流转化为一眼可读的监督界面十二种渲染分类render class如何划分信息的阅读频率与后果权重以及该设计在桌面端代码中如何以分类器、分组器与渲染器三层管线实现。文中所有实现细节均以当前仓库源码与测试为依据可对照验证。一、问题背景为什么原始 IO 转储不是窗口When you delegate work to an agent, you are trusting a process you cannot see. The activity feed is the window into that process — but a window is only useful if you can read it at a glance.把工作委托给 Agent本质是信任一个不可见的过程。活动流是这个过程的窗口但窗口只有在可以一眼读懂时才有价值。原始输入/输出转储raw input/output dump不是窗口而是需要解码的转录稿transcript——它强迫你先parse解析再judge判断这在监督场景中是致命的延迟。该愿景在 VISION_ACTIVITY.md 中给出的目标是让开发者像监督一名得力队友一样监督代理——扫一眼看进度、信任常规操作、只捕捉需要自己的那一件事而不必逐行阅读。这个理念在桌面端代码中体现为对「原始事件」与「语义卡片」的刻意分层原始 ACP 帧raw_json_rpc会被归入 metadata 噪声门正常叙事流中不渲染只有按需进入 raw rail见下文。从源码结构看桌面端由ObserverEventagentSessionTypes.ts承载来自 relay 的原始事件再由转录构建管线转换成语义化条目。二、服务对象与三大问题理解、信心、控制活动流服务于监督委托方的开发者。他不是为了娱乐而观看而是在决定是否介入。因此feed 中的每一项都必须通过回答以下三个问题来赢得它占据的像素Comprehension理解—— 它在做什么为什么Confidence信心—— 进展顺利还是卡住或出错了Control控制—— 我需要介入吗从哪里介入能即时回答这三个问题的 feed能把事件流转化为轨迹感trajectory回答不了的 feed只是带滚动条的噪声noise with a scrollbar。在实现层AgentActivityToneread | write | admin | neutral见 agentSessionTypes.ts正是为回答「信心/控制」问题而设计的维度写操作与管理操作被赋予更响亮的呈现读操作则安静地退居次席。三、统摄框架动词-对象-结果Verb, Object, Outcome活动流中每个有意义的条目都是一句话agent 对 [对象] 做了 [动词] → [结果]。Sent a message to #design. · Editedruntime.rs(12/−3). · Reacted to Marges review. · Ran tests → 1248 passed.feed 的职责是第一时间呈现动词、对象、结果并把支撑细节——完整参数、原始输出、完整 diff——推入渐进式披露progressive disclosure。你读句子只有句子让你想看时才展开。这一框架在代码中有直接对应物AgentActivityAction类型{ verb: string; object?: string | null }见 agentSessionTypes.ts与AgentActivityDescriptor中的label、preview、action、object字段。而分类器负责从工具调用中提取动词buzzOperationVerb把操作映射为规范动词add→Added、create→Created、delete→Deleted、get/list/members→Read、send→Sent、search→Searched等agentSessionToolClassifier.tsbuzzOperationObject把操作名还原为可读对象如messages→ message从而拼出 Sent message to #design 这类句子同文件 L433-L444。四、十二种渲染分类Render Classes完整的事件分类学每个事件最终都解析为十二种呈现类别之一按被阅读的频率与承载后果的大小组织4.1 脊柱层The spine—— 常读常新类别含义MessageAgent 的声音对外发言Buzz relay op在平台上的实际操作File-edit真正的代码工作Shell commandAgent 的双手Tool status turn lifecycle心跳回合生命周期如果这五类不清楚feed 就是失败的。4.2 高价值上下文High-value context—— 用于判断正确性类别含义Thought推理过程随取随用Plan/Todo路线图与进度条Permission控制闸门Error停止标志4.3 环境安全网Ambient safety net—— 很少读但必须存在类别含义Generic tool诚实的兜底呈现Raw rail按需取用的地面真相ground truthSuppressed noise我们刻意不渲染的内容关键论断这不是愿望清单而是完整的分类学——Agent 能发出的每个事件恰好落入其中一个类别而最后三类保证了永远存在「地板」。代码侧完全印证了这一「穷尽性」承诺AgentActivityRenderClass在 agentSessionTypes.ts 中定义为 15 个值的联合类型message、relay-op、file-edit、file-read、skill-read、image、shell、status、thought、plan、permission、error、generic、raw-rail、suppressed——其中读类在实现中被细分为 file-read / skill-read / image 三类对应文档十二类的读操作家族而路由表 TranscriptActivityItem.tsx 用satisfies RecordAgentActivityRenderClass, ActivityRenderClassPresenter声明了从每个渲染类到呈现组件的穷尽映射——TypeScript 会在新增渲染类时强制补齐对应组件从编译期保证了「每个事件都有归属」。五、九条设计原则与源码印证5.1 语义优先于传输Semantics over transport渲染agent 做了什么而不是它用了哪个 API。通过 MCP 工具发送的消息与通过 shellbuzz命令发送的消息渲染为完全相同的卡片。Agent 如何到达 relay 是管道细节做了什么才是契约。代码印证AgentActivityDescriptor.sourcemcp | shell | acp | harness | fallback只用于调试标注不决定渲染类别。分类器classifyBuzzTool与parseBuzzCliCommand殊途同归——前者识别 MCP 工具名如send_message后者解析 shell 命令 token如buzz messages send ...两者都产出renderClass: messageagentSessionToolClassifier.ts证明「同一语义、同一卡片」在实现层成立。5.2 结果优先Outcome-first以成功、失败或结果开头。读者在一秒内决定是否展开。原始转储是兜底绝不是标题。代码印证classifyTool在识别出语义类别后一旦isError为真立即把渲染类升级为error并给标签追加 failedagentSessionToolClassifier.ts——失败永远占据最响亮的呈现位置。5.3 原地更新Mutate in place正在执行的动作在其自身行内从 pending → executing → done/failed 更新。一个动作就是一个条目而不是一串重复的状态行副本。代码印证ToolStatus executing | completed | failed | pendingagentSessionTypes.ts与TranscriptItem的startedAt/completedAt字段均为单条目多状态模型服务。5.4 永不失明Never go dark事件的缺席本身也是信息。Silence、idle、timeout 是被渲染的状态——waiting…、timed out——而不是空洞。这镜像了项目对 Agent 的规则如果你没展示它它就没发生if you didnt show it, it didnt happen。5.5 失败上扬、阅读退后Failures rise; reads recede显著性salience跟随后果。管理操作、写入、错误是响亮的读取和推理是安静的。被埋没的错误就是坏掉的 feed。代码印证AgentActivityTone的 read/write/admin 三分法直接驱动显著性buzzCliTone依据动词组判定音调BUZZ_CLI_ADMIN_VERBS→ admin、BUZZ_CLI_READ_VERBS→ read见 agentSessionToolClassifier.ts 与 L446-L451。5.6 解析引用Resolve references展示 #design、Marges message、文件名——绝不是一个原始 event id 或 pubkey。读者用名字思考不用哈希。5.7 合并流Coalesce streams分块的文本合并为一个条目。开发者读的是消息不是包追踪packet trace。代码印证这是实现中最精细的部分之一。agentSessionTranscriptGrouping.ts 实现两遍工具分组第一遍same-kind把同groupKey的连续运行折叠成带具体标签的摘要——Read 3 files、Edited 2 files、Ran 4 commandssameKindLabelL365-L380第二遍mixed burst把不同种类交错的常规工具工作折叠成 Ran N tool calls 摘要并且容忍交错search → read-summary → search → read-summary 可合并为一行监督记录关键边界消息、权限、错误/失败工具、status/suppressed 行永不参与分组且会打断 run——保证介入点始终可见isGroupingEligibleL351-L357。这与 5.5「错误不能被埋没」互为表里。5.8 诚实胜过猜测Honesty over guessing被识别的操作得到语义卡片未被识别的则降级为干净、真实、通用的行。绝不为了显得更丰富而编造语义。代码印证分类器按「load_skill → developer harness tool → buzz tool」三级providers链尝试agentSessionToolClassifier.ts全部未命中时落入genericDescriptor渲染类为generic、label 为 Ran tool、source 标记为fallback——诚实兜底被显式建模。5.9 默认打磨、按需原始Polished by default, raw on demand策展curation是产品本身raw rail 是安全网。二者之间的切换是同一真相的不同缩放级别而不是两个不同的 feed。代码印证RawRailActivity组件把 metadata 条目渲染为可折叠的 section 列表raw_json_rpc原始负载默认收进details折叠区点击才展开pre原始文本RawRailActivity.tsx同时该渲染类的专属渲染测试覆盖了原始载荷路径RawRailActivity.render.test.mjs。六、噪声门与「脊柱」识别让信号可读的隐藏机制「决定不显示什么」与「决定显示什么」同样重要。实现中有两层噪声治理噪声门noise gateisMeaningfulItem过滤掉被抑制的工具行renderClass suppressed、生命周期噪声turn started、session ready、wire parse error以及原始 JSON-RPC 帧raw_json_rpc见 agentSessionTranscriptPresentation.ts脊柱识别spine detectionisSpineItem判定哪些条目是「脊柱工作」工具、消息、思考、计划、有意义的生命周期事件metadata系统提示、提示上下文属于应退后的阅读类BotActivityBar 用它做两档标题扫描——先收集脊柱标题找不到时再回退包含 metadata避免会话开始/空闲时栏为空L86-L100。SuppressedActivity渲染器则负责把「刻意不渲染」的内容以最小化行呈现只显示动词-对象与耗时SuppressedActivity.tsx。典型例子是开发 harness 的stop_hookChecked todos——它是心跳级动作展示语义但占据最少像素agentSessionToolClassifier.ts。七、会话边界与回合组织长时监督的秩序感feed 需要处理多会话、多回合的长时运行。buildTranscriptDisplayBlocks负责把扁平、按时间排序的条目流组织成展示块agentSessionTranscriptGrouping.ts会话边界session-boundary当条目跨越多个会话归档历史 实时会话时在连续会话运行之间注入分隔块并区分三种标签状态current最新可见且匹配 relay 实时会话、most-recent最新可见但会话已结束、earlier更早的会话——让「当前上下文」与「历史」永远清晰回合分组turn bucket同一turnId的条目聚合为一个回合块回合内再细分 prompt用户提示 上下文 setup 生命周期、活动段与摘要段边界键稳定性会话边界块的 React key 使用firstItemId对前置插入稳定而非runIndex避免归档页加载更早会话时引起边界节点不必要的重挂载L754-L764。这些机制共同构成「永不丢失」的保证restart 时session/new标记会暂时驻留缓冲直到新会话解析后重新锚定流在重启中途结束时则把缓冲刷回当前会话——任何条目都不会被静默丢弃。八、这一设计换来了什么赢得委托Earning Delegation活动流真正的工作是赢得委托earn delegation。可见的进度、可见的同意、可见的结果是复合增长的每一次你看到回合顺利进行的观察都让你更信任 agent 去承担更大的回合。决定不显示什么——抑制心跳与内部闲谈——与决定显示什么一样是功能因为抑制正是让信号可读的原因。这一 feed 在基础上是协议诚实protocol-honest的任何符合规范的 agent 的消息、思考、工具调用、回合都会成为一等公民条目无论它运行的是什么工具。而 Buzz 专属的丰富层——语义 relay 卡片、buzz-CLI 解析器、diff 渲染——是其上的一层增强而非其下的硬性要求。非 Buzz 代理获得正确、可读的 feedBuzz 代理获得原生native的 feed。同一真相的两个高度打磨版供判断原始版供调试。窗口始终是窗口。这句话在代码中的落点是TranscriptActivityItem用一张穷尽的路由表在同一个 DOM 流里渲染所有呈现类TranscriptActivityItem.tsx而RawRailActivity在同一流中以折叠姿态存在——两者不是两个 feed而是同一个真相的两种缩放。九、延伸阅读愿景文档VISION_ACTIVITY.md渲染类路由与穷尽映射desktop/src/features/agents/ui/activityRenderClasses/TranscriptActivityItem.tsx类型定义渲染类、音调、动作、条目联合类型desktop/src/features/agents/ui/agentSessionTypes.ts工具分类器Buzz MCP 工具 / buzz CLI 解析 / 兜底desktop/src/features/agents/ui/agentSessionToolClassifier.ts流合并与两遍分组、会话边界desktop/src/features/agents/ui/agentSessionTranscriptGrouping.ts标题生成与噪声门desktop/src/features/agents/ui/agentSessionTranscriptPresentation.ts十二类呈现组件目录desktop/src/features/agents/ui/activityRenderClasses/相关测试渲染路由与分组行为见 agentSessionTranscriptGrouping.test.mjs、agentSessionTranscriptPresentation.test.mjs、RawRailActivity.render.test.mjs【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考