人有余光,agent 没有 —— 为什么信号需要被管理

MATTHEW · 2026-08-13 · THINKING NOTE

人有余光,agent 没有
—— 为什么信号需要被管理

一则关于人机混编组织的观察

最近在想一件事:我们的工作方式其实已经变了——不再是纯人类团队,而是人和 agent 混编在干活。这个变化里,有一个容易被忽略的断裂。

一、断裂:余光的消失

人类组织里,信号是弥散的。你扫一眼群、瞟一下监控大盘、听到隔壁同事顺嘴一提——协调就这样在共享环境的「余光」里完成了。余光如此便宜、如此自然,以至于从来没有人需要「设计」它。

但 agent 没有余光。它不会顺便看见什么,不会无意间听到什么。agent 的每一分「知道」,都必须被显式地投递给它。团队里的 agent 越多,这个问题就越大:以前免费获得的信号织物,现在必须显式重建。

纯人类组织 · 信号是弥散的 扫一眼群 · 瞟一下大盘 · 听一嘴 —— 协调在「余光」里免费完成,无人需要设计它 人机混编组织 · 信号必须显式 agent agent 信号层 显式投递·留痕 agent 没有余光:每一分「知道」 都必须被显式投递、被管理、可追溯

左:信号弥散在共享环境里(虚线=余光)· 右:信号必须经过显式的层(实线=投递)

二、压力:注意力成了最稀缺的资源

另一面是注意力。agent 让执行力可以横向扩展——多开几个 agent,产出就上去了。但人的注意力不能横向扩展,一个人还是只有一份。

执行扩展、注意力不扩展,「什么值得进入我的注意力、什么时候、以什么形态」就从体验问题变成了核心的资源分配问题。回头看我自己最近的行为,其实一直在手工做注意力配给:调试噪音和正式通知必须分群、只认明确语句的授权、不许随手往共享环境里倒垃圾信息。每一条土规矩,本质都是在缺一个信号系统的情况下,用人肉扮演那个系统。

三、同一个模式的第三次出现

想到这里我发现一件更有意思的事:这不是我第一次建这种东西。

在做信号之前,我已经花了很长时间给自己和 agent 建记忆的基础设施——知识和上下文被当作一等对象管理:怎么捕获、怎么记录、新事实怎么取代旧事实、怎么投影、留存多久。现在做信号,机制几乎押韵:接受、记录、新信号关联并取代旧信号、路由、留存多久。往后看,工作也一样——任务怎么产生、执行、留证、收尾。

底下其实是同一个理念:一切重要的流动物,都应该被当成一等对象,管理它的一生。组织至少有三种这样的流动物——记忆(它知道什么)、信号(它觉察并要求什么)、工作(它去做什么)。知、觉、行。

为什么现在轮到信号?因为信号恰好是另外两者之间的流动介质:知道的事要变成觉察,觉察的事要变成行动,中间那条通道就是信号。纯人类组织里这三样都由人脑和聊天软件兜着;人机混编之后,每一样都得显式建出来,而且要为人和 agent 同时设计——它们在层级上是对等的行动者,都能接收信号,也都能发出信号。

四、历史每次都这么演

组织规模一旦超过「余光可达」,就必然发明信号基础设施——驿站、军队的信号兵、电报、公司的备忘录制度,都是各自时代的答案。

古代的通政司干的就是这件事:奏折是事件,入档供查;廷寄是通知,让该知道的人知道;六百里加急是告警,要人立刻注意;圣旨是最重的那种——既要你的注意力(跪接),也课你以行动的义务(奉旨办差),办完还得复命(回执)。有路由,有驿传投递和重发,有存档,有「谁有资格递折子」的权限。皇帝只有一个人,奏事的人和机构却越来越多——这跟今天「一个人带一群 agent」的处境,是同构的。

五、收束

所以结论收成一句:我们的组织正运行在「执行力已经 agent 化、注意力还是单人份」的裂缝上,而弥合这道裂缝的东西,在一切时代都叫信号系统。通知太乱只是导火索——即使没有那根导火索,走到这里也是迟早的事,证据就是我在想信号之前,已经不自觉地先建了一个同构的记忆层。

留一个我自己也还没想透的问题:知、觉、行三层,我先建了「知」,现在建「觉」——这个顺序是巧合,还是一个组织本来就得先记得住、再感知得到、最后才配行动?如果是后者,工作层该怎么设计,其实已经被前两层决定了。欢迎来聊。

(最近在做的 tap-signal 就是在补信号这一层,第一个场景——CI/CD 通知统一——已经在生产跑了。下面附上这一层的设计哲学。)

附一、这一层长什么样:信号管理器

tap-signal 的定位不是「通知工具」,而是信号管理器——管理一条信号的一生:接受、记录、处理、路由、配置、权限。它居中,所有参与方对称:任何人或系统要与它交互,都以「提交事实」的身份从同一个入口进来——CI/CD、监控、平台事件是这样,人和 agent 也是这样。「出口」不是另一类实体,只是某个参与方在这一条信号里恰好处于接收端;下一条信号里它可能就是来源。

信号层 管理信号的一生 ① 接受 ② 记录 ③ 处理 ④ 路由 ⑤ 配置 ⑥ 权限 不编排工作 · 不下结论 · 不持工作执行凭据 每条信号可解释:按什么规则 · 发到哪 · 结果如何 CI/CD 流水线 提交事实 监控 / 告警系统 提交事实 平台事件(GitHub…) 提交事实 人(行动者) 接收卡片 · 也可提交 人工发起的信号 agent(行动者) 接收结构化移交(跨层信号) 工作结果可作为信号提交 (非必然——进入是选择不是镜像) 哲学:入口统一,参与方对称 ① 任何参与方——包括人与 agent——要与信号层交互,都以「提交事实」进入同一套入口契约。 ② 差别只在接口形态(内部可信 / 对外开放),体现为鉴权强度与暴露面,不构成层级差异。 ③ 接收端只是角色:参与方的产物不必然回流;但凡要进入本层,就以一条新信号的身份进来。

双向箭头=既可接收也可提交 · 虚线=尚未实现的行动者形态

交互模块加载中 …(需可访问 CDN)
notification 告知 → 人
alert 唤起 → 人
action 委托 → agent
summons 召令 → 人(须复命)

信号的一生,实时模拟:三个来源提交事实(墨色)→ 信号层内定性上色 → 按「信号 × 接收者」路由;约一成被抑制、坠入沉淀托盘留痕,召令抵达后有回执粒子复命。拖拽可旋转视角。

附二、信号的一生:九段

一条信号的传记:产生 → 接受 → 定性 → 裁决 → 加工 → 传达 → 回响 → 关联 → 沉淀。其中三条最重要的裁定:

产生 层外·语境 接受 一生自此始 定性 只校验申报 裁决 否决也留痕 加工 按接收者塑形 传达 重试·终态 回响 选择性事实 关联 不可变注解 沉淀 可查的死后

虚线段=选择性(非每条信号必经)

① 谁也没到达的信号也有完整的一生。任何「不投递」的决定(抑制、静默、零接收者)都必须留痕记原因——沉默也是一种被记录的裁决。
② 回响只记不判。确认、回执、审批决定都可以作为新信号回来;信号层存储与索引它们,但不解释语义、不跑催办定时器——那是 on-call 系统的领域。
③ 「进行中的事态」是投影不是状态。告警的 firing 和 recovery 是两条点状信号加一个关联键;「事故还开着」是查询时算出来的视图,信号层自己不持有世界的状态机。

附三、信号的类型:两个开关,四个名字,一道圣旨

信号类型的本质不是四选一的枚举,而是两个独立的开关:要不要对方的注意力 × 课不课以行动的义务。四个格子四个名字:

行动义务 = 无 行动义务 = 有 注意力 = 无 注意力 = 有 notification · 告知 让你知道即可 · 已上线 例:构建成功的绿色卡片 action · 委托 要你做,可排队 · 带回执 例:派工给 agent,不催 alert · 唤起 要你现在注意 · 可记录确认 例:生产告警 summons · 召令 👑 圣旨:必须现在听好,然后马上去做 例:审批请求、紧急派工 · 办完复命

event 不在格子里——它是「发生了什么」维度的词,不是「期望你怎样」维度的词

还有一条不显眼但关键的设计:这份契约长在「信号 × 接收者」的那条边上,不长在信号上。同一条告警可以对值班的人是唤起、对诊断 agent 是委托;同一个告警家族里,firing 那条要人立刻注意,recovery 那条只是报个好消息。谁该被怎样对待,由平台侧的路由裁决说了算——调用方提供事实,平台决定投递行为。

(以上模型的完整版——包括被对抗评审否决的三个初版方案和否决证据——在 tap-signal 的设计文档库里。怎么接入,后面单独写。)

MATTHEW · 2026-08-13 · 欢迎转发讨论

Leave a Reply

About Me
Matthew Hong’s work avatar

I’m Matthew Hong, an engineer focused on architecture, standards, and documentation — and, increasingly, on the philosophy of how humans and agents work side by side. Matthew Labs is where I think out loud about how we build, organize, and work in the AI-native era.

Currently @ TapNow

matthewohmygosh@gmail.com

@Matthewohmygosh

Discover more from Matthew Labs

Subscribe now to keep reading and get access to the full archive.

Continue reading