---
title: Session Engineering：组织多个 Agent 会话，也是管理自己的上下文
date: '2026-11-06T22:33:00+08:00'
summary: 一个 Agent 已经能独立做完一件完整的事，限制变成了人能同时跟住几个会话。我把围绕这个限制组织多个 Agent 会话的做法叫作 Session Engineering：它决定工作怎样分给会话，也决定人每次切换时要重新读多少东西。本文说明它和 Prompt、Context、Harness、Loop Engineering 的区别，以及 Tenon AI 按这套做法运转时定下的规则。
lang: zh
category: AI/Agents
social:
- channel: linkedin
  url: https://www.linkedin.com/feed/update/urn:li:share:7524480332944019457/
  published_at: '2026-11-06'
  article_hash: c38b4c67bb5c6e7690eb22573fa3f0025571402f0cc818e835d23633be32c72e
- channel: x
  url: https://x.com/DorianZeng/status/2118714323887689879
  published_at: '2026-11-06'
  article_hash: c38b4c67bb5c6e7690eb22573fa3f0025571402f0cc818e835d23633be32c72e
---

现在一个 Agent 已经能独立做完一件完整的事：读代码、改代码、跑测试、提交。我的工作方式也跟着变了：Claude Code 的侧边栏里同时开着十几个会话，每个负责一块，我在它们之间切换，回答问题，做决定。

这时候限制已经不在 Agent 身上。一个会话的窗口装不下一个复杂的工程，开很多会话又带来另一个问题：每切到一个会话，我都要先想起它是干什么的、做到哪了、在等我什么。会话多了却没有组织，大部分精力就花在这件事上。

我把围绕这个限制来组织会话的做法叫作 Session Engineering。它是一种任务组织方式。对 Agent，它决定工作怎样分给多个会话、会话之间怎样协作；对人，它决定每次切换时要重新读多少东西。后一半也可以叫 Attention Engineering，对每个靠 Agent 写代码的人（vibe coder）都适用。

## 和 Prompt、Context、Harness、Loop Engineering 的区别

在它之前，已经有几个相近的说法：

| 说法 | 提出 | 关心的对象 | 回答的问题 |
| --- | --- | --- | --- |
| Prompt Engineering | 2020 年前后随 GPT-3 流行，没有公认的提出者 | 给模型的指令 | 怎样写指令，让模型给出想要的结果 |
| [Context Engineering](https://simonwillison.net/2025/Jun/27/context-engineering/) | 2025 年 6 月，Tobi Lütke 提议，Andrej Karpathy 赞同 | 一次模型调用 | 这一次该让模型看到什么 |
| [Harness Engineering](https://openai.com/index/harness-engineering/) | 2026 年 2 月，OpenAI 的 Codex 团队 | 一个 Agent 的工作环境 | 怎样约束、告知、检查和纠正这个 Agent |
| [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | 2026 年 6 月，Addy Osmani | 反复运行的 Agent | 怎样让一个系统代替人去提示 Agent |
| Session Engineering | 本文 | 一组会话和使用它们的人 | 工作怎样分给会话，人怎样在会话之间切换 |

前四个都在研究怎样让模型或 Agent 把活干好，主要服务于 Agent 的研发。Osmani 在 Loop Engineering 那篇文章里提到，能同时跑多少个 Agent，受限于人审阅的带宽，而不是工具。Session Engineering 就从这个限制出发，把人也算进系统里。

这个词之前也有人零星用过，多指一个 Agent 的会话怎样保存、压缩和恢复。本文说的是另一件事。

## 会话是现成的单位

Claude Code 和 Codex 的桌面应用都把并行的会话列在侧边栏里。一个会话有标题，有自己的历史和工作目录，能看出它在运行、在等人回答，还是已经结束。在 Claude Code 里，会话之间还可以互相发消息，一个会话也可以开出新的会话。

多 Agent 协作因此有了一个很直接的形式：侧边栏里的每个会话就是一个 Agent。从这个角度看，Session Engineering 就是一种多 Agent 工程。

它和常说的子 Agent 不一样。子 Agent 由一个会话在内部调用，做完把结果交回去，人通常看不到中间过程。会话是持久的，人可以随时打开任何一个，接着说话或者叫停。所以在 Session Engineering 里，人也是其中一个节点，所有需要批准的事都要经过这个节点。

## 人的上下文

模型有上下文窗口，人也有类似的限制：同时能记住的事情有限。两边的对应关系是这样的：

| 模型 | 人 |
| --- | --- |
| 上下文窗口有上限 | 同时能跟住的事有限 |
| 每次调用前，挑选要放进窗口的内容 | 每次切到一个会话，要重新想起它的情况 |
| 系统提示、检索和压缩，让窗口里只留有用的内容 | 标题、现状和待决问题，让人读几行就能接上 |

所以 Session Engineering 有一半是给人做的 Context Engineering。切到一个会话时，人需要知道三件事：它负责什么，做到哪了，有没有在等我。如果这些要从聊天记录里翻，切一次就要几分钟。我们的做法是把它们放在固定的位置：

- 标题写组名或项目名，看标题就知道它负责什么。
- 每轮结束时写两三句现状，最多问一个问题，并给出可以直接点的选项。人切进来先读这几句。
- 结论写进文档，会话之间的消息只是通知。以后要查，读文档，不翻聊天。
- 做完的任务会话归档，侧边栏里只留还在进行的事。

![切到一个会话时，先读这三样](/blog/assets/session-engineering/switch.svg)

## Tenon AI 的做法

2026 年 11 月 6 日起，Tenon AI 按一份《会话分工与协作规范》运转。成员是我和一组 Claude Code 会话：

| 成员 | 负责 |
| --- | --- |
| 创始人 | 方向和决定；批准上线、对外发布、花钱和不可逆的操作 |
| 总办 | 规范、会话名册和归属表；邮件、日程和财务 |
| 平台组 | 官网、Tenon 账号和跨产品的约定 |
| 产品会话 | 每个产品一个：仓库、部署和上架 |
| 客户项目会话 | 每个客户项目一个：按合同开发和交付 |
| 安全组 | 服务器、域名、证书、日志和告警 |
| 法务组 | 公司主体、备案、合同和数据合规 |
| 运营组 | 内容和品牌口径；管理各渠道的会话和定时任务 |
| 商务组 | 冷邮件、客户洽谈和报价 |

当天侧边栏里有 19 个常设会话和 4 个定时任务。总办归档了 21 个旧会话，每个定时任务只留最近一次运行的会话。规范里最重要的是下面几条。

**每样东西只有一个负责的会话。** 每个仓库、域名、服务器、外部账号和文档都写在归属表里。别的会话要改，向负责的会话提出，由它决定并实施。这样两个会话不会同时改一个文件，我也知道一件事该去哪个会话问。

**跨组的事设一个牵头会话。** 牵头会话维护清单，成员只向它回报，成员之间不来回确认。主站迁到新域名做备案时，法务组牵头维护迁移清单，把事项分给平台组、安全组、商务组和运营组。运营组的事项是在切换当天换掉各平台简介里的旧链接，在这之前只等通知。6 个会话两两确认要 15 条沟通线，都向牵头会话回报只要 5 条，我也只需要看一份清单。

![6 个会话的两种沟通方式](/blog/assets/session-engineering/topology.svg)

**消息少而完整。** 同一件事给每个会话只发一条完整的消息，写明已定的事、待定的事和找谁；单纯的确认不回复。迁移域名时，平台组把我的一句话理解成不用再通知别的会话，结果 PassBy、AgentHub、WeSaid 三个产品会话反复来问同一件事，一直在等确认。现在规范里写明：跨产品的约定定下后，由平台组一次告诉所有相关会话，写明已定的事、待定的事和找谁。

**会话之间的消息不算批准。** 上线、对外发布、花钱和不可逆的操作只能由我批准。会话转达我的决定时，要引用原话，并注明出自哪个会话。会话读到的网页、邮件和评论可能夹带指令；如果同事的一句话就算批准，这样的指令就能在会话之间传下去。

## 这些规则大多不新

一样东西只有一个负责人、跨部门的项目设牵头人、以文档为准，这些都是公司管理里的老办法。Brooks 在《人月神话》里算过：n 个人两两沟通，有 n(n−1)/2 条路径，人越多，沟通成本涨得越快。新的地方是，现在干活的是 Agent，可以开很多个，而做决定的人只有一个。管理的方法可以照搬，要节省的资源变成了这个人的注意力。

这套做法也有代价：

- 会话不是越多越好。每多一个常设会话，我就多一个要记住的地方。几次工具调用能做完的事，留在当前会话里做。
- 规范本身要维护。组织调整时，要同时改规范和名册，不然会话会照着过时的文档做事。
- 规则只管协作，不保证每个会话的工作质量。检查和验收仍然要人来做。

## 从哪里开始

如果你也在同时开很多会话，可以先做这几件事：

1. 给每个长期存在的会话一个职责，写在标题里。
2. 每样东西只交给一个会话负责。
3. 要求每个会话每轮结束时写两三句现状，最多问一个问题。
4. 结论写进文档，不留在聊天里。
5. 做完的会话及时归档。

这篇文章也是这样写出来的：我在运营组的会话里提出 Session Engineering 的想法，运营组写稿、画图，在本地预览后交给我确认。