---
title: Session Engineering（二）：加一层总办，人只对接一个会话
date: '2026-11-08T11:34:00+08:00'
summary: 11 月 7 日晚上，要我处理的事攒了二十多件，分散在十几个会话里。之后我们加了一层总办：各会话把要我定的事发给总办，总办整理到一个待办页，我在手机上点选、统一发送，再由总办转回各会话执行。本文写这一层怎么运转：请求怎么写，总办怎么分流，转达的决定怎样算数，会话之间的消息额度，以及几项可以对照的历史制度。
lang: zh
category: AI/Agents
social:
- channel: linkedin
  url: https://www.linkedin.com/feed/update/urn:li:share:7525039342319374337/
  published_at: '2026-11-08'
  article_hash: 5d748b1ef80178d8c507b2b072061b1f9407ebf7b719d608ad4a6b2c7c365da0
- channel: x
  url: https://x.com/DorianZeng/status/2119273377563304348
  published_at: '2026-11-08'
  article_hash: 5d748b1ef80178d8c507b2b072061b1f9407ebf7b719d608ad4a6b2c7c365da0
---

上一篇《[Session Engineering：组织多个 Agent 会话，也是管理自己的上下文](/blog/session-engineering/)》写了 Tenon AI 从 11 月 6 日开始的分工：每样东西只有一个负责的会话，跨组的事设一个牵头会话，会话之间的消息不算批准。规则定下的第二天晚上，出现了一个上一篇没有解决的问题。

## 二十多件事，分散在十几个会话里

11 月 7 日晚上，各会话攒下了二十多件要我处理的事：要我拍板的决定，要我登录或者在手机上操作的步骤，要我确认的对外文案。它们分散在十几个会话里，我要逐个切进去，读完上下文再回答。

上一篇说过，每切到一个会话，人都要先想起它负责什么、做到哪了、在等我什么。每个会话都把这三件事写清楚以后，切一次快了很多；但只要要我处理的事分散在各处，切换的次数就省不掉。

## 加一层：总办

做法是让我只对接一个会话，就是总办。其他会话把要我定的事发给总办，不直接找我；总办整理好交给我，我决定后再由总办转回去。

| 角色 | 负责 | 不做 |
| --- | --- | --- |
| 人 | 方向、决定、验收；亲自确认对外而且不能撤回的动作 | 具体实现；逐个盯着会话 |
| 总办 | 人的唯一入口：待办页和决定记录；转达；分流；规范和名册；每周汇总 | 写代码、改产品 |
| 组（牵头会话） | 一类事的负责人，比如平台、安全、法务、运营、商务；管下面的会话和定时任务，代转通知 | 别的组的事 |
| 执行会话 | 一个产品、一个项目或一件具体的事；职责内自己判断 | 改别人负责的东西 |
| 定时任务 | 按时做固定的事，结果报给所属的组 | 越出任务说明 |

层级是人、总办、组、执行会话，三到四层。每多一层，转达就多一次，所以只在会话多到总办直接管不过来时，才加「组」这一层。现在运营组下面管着三个渠道会话和四个定时任务，就是这种情况。

产品的需求、功能和设计是例外：这些我还是在各个产品的会话里直接打磨，不经过总办。

![人、总办、组和执行会话](/blog/assets/session-engineering-chief-of-staff/structure.svg)

## 请求怎么写

发给总办的请求，一件事一条消息，写清六项：

1. 要定什么；
2. 建议和备选；
3. 期限；
4. 涉及哪些会话；
5. 能不能撤回；
6. 定了以后谁做什么。

标准是不看提出请求的那个会话，也能做决定。这和上一篇说的「每轮结束写两三句现状」是同一个思路：让读的人不用回去翻聊天记录。

向总办只报三类事：要我决定或操作的事，我交办的事的结果，风险和事故。日常进度写在各自的文档里，由总办每周汇总。

## 总办会退回请求

总办不只是转发。职责内能自己判断的事，不该发给总办：只动自己负责的东西、能撤回、不花钱，也不对外。这类请求到了总办，会被直接退回去，并说明理由。几个会话为同一件事发来的请求，总办会合并成一件。

## 待办页

总办把要我定的事放在一个页面上。每件有编号、类型（决定还是操作）、来源、期限、说明和几个建议项，推荐的那项标出来，我可以加备注。页面每次都列出全部待办，按期限排序。

我在手机上逐件点选，最后统一发送。页面通知总办，总办把决定转回各会话执行，再把这件移到「已办」，写上结果。第一次提交了 13 件，几分钟就处理完了。

页面上的选择只有我自己的账号能写，可以当作授权的凭据。总办同时把决定写进仓库里的决定记录，写明日期、决定、我的原话或页面上的选择、转给了谁。我也可以直接在总办的会话里回编号，比如「Q3 不改」。

![待办页上的一件事](/blog/assets/session-engineering-chief-of-staff/inbox.svg)

## 转达的决定怎样算数

总办转达的决定，视同我本人的决定。转达里会引用我的原话，或者待办页上的编号、选择和备注；接收的会话可以到决定记录里核对，然后照办职责内的事。其他会话之间的消息，仍然不算批准。

例外是本来就要我批准、又对外而且不能撤回的动作：提交审核、首次上线、付款、以公司名义给外部的人发信、删除数据、改账号的安全设置。这类动作，执行的会话可以要求我在它自己的会话里确认一次。11 月 8 日凌晨，WeSaid 的新版本要提交 App Store 审核，负责 WeSaid 的会话没有接受总办的转达，最后由我在浏览器里点了提交。理由是接收的会话无法证实一段转达就是我本人的意思；一个会话出错或被误导时，这一步能挡住不可逆的后果。代价是我多点一下。

日常动作另有常设授权，比如各渠道的日常内容审完直接发，写在各组的文档里，不用每次请示。

## 消息额度

会话之间发消息有额度。我们遇到的限制是：人每发一条消息，一个会话最多给其他会话发 10 条，超了就暂停，等人再发消息。应对的办法有四个：

- 同一个会话的几件事并成一条；
- 发给全部会话的通知，交给各组的牵头会话代转，每个会话的额度分开算；
- 额度用完时，我在总办的会话里随便回一句；
- 待办页的页头显示总办还剩多少额度。

## 可以对照的历史制度

一个人通过一层机构处理大量请求，历史上有过几种做法。它们和这里的对应关系如下：

| 制度 | 原来的做法 | 对应到这里 |
| --- | --- | --- |
| 唐代三省六部 | 中书省起草，门下省审核，可以封驳退回，尚书省交六部执行 | 会话起草请求，总办审核分流，我决定，会话执行；总办要能把不该上报的请求退回去 |
| 明代票拟、批红 | 内阁在奏章上拟好处理意见，皇帝用朱笔批准；批红后来交给司礼监代行，出过大问题 | 总办给每件待办附上建议项，我点选；不可逆的事不由总办代批 |
| 虎符 | 调兵要两半虎符合在一起才算数 | 对外不可逆的动作，要我的确认和总办的转达同时具备 |
| 任务式指挥 | 上级只下达意图，下级自己决定怎么做 | 写清职责和常设授权，会话在职责内自己判断，不事事请示 |

## 这一层的代价

- 转达多了一次。总办转错或漏转，会话就会按错的做，所以决定要写进决定记录，接收的会话可以核对。
- 总办的上下文也有限。会话的上下文会被压缩，所以规范、名册、待办清单和决定记录都写在仓库的文件里，不靠总办记在聊天里。
- 换一个平台，这套做法要重新搭。我们把和平台无关的部分整理成了一份通用规范。换平台时先确认目标平台有没有这六种能力，缺哪一项，就用文件加人工转达补上：
  1. 多个能长期运行、各有上下文的会话；
  2. 会话之间能传话，或者能读写同一组文件；
  3. 一个能在手机上点选、提交后能通知到总办的页面或表单；
  4. 所有会话都会读的说明或记忆文件；
  5. 定时任务；
  6. 会话执行对外动作前，要人确认的机制。

## 现在的样子

现在我一般只在总办的会话里回复。各会话的请求在总办那里排好，我有空时打开待办页处理一批；产品的需求仍然在各个产品的会话里直接打磨。

这篇文章也走的这条线：我在总办的会话里说想写这篇，总办把素材转给运营组，运营组写稿、画图、在本地预览，再把要我确认的事交给总办，放进待办页。