Session Engineering：组织多个 Agent 会话，也是管理自己的上下文
Session Engineering: organizing agent sessions is also managing your own context
一个 Agent 已经能独立做完一件完整的事，限制变成了人能同时跟住几个会话。我把围绕这个限制组织多个 Agent 会话的做法叫作 Session Engineering：它决定工作怎样分给会话，也决定人每次切换时要重新读多少东西。本文说明它和 Prompt、Context、Harness、Loop Engineering 的区别，以及 Tenon AI 按这套做法运转时定下的规则。
An agent can now finish a complete piece of work on its own, so the limit has become how many sessions one person can keep track of. I call the practice of organizing agent sessions around that limit Session Engineering. It decides how work is split across sessions and how much a person has to reread at each switch. This post compares it with Prompt, Context, Harness and Loop Engineering, and describes the rules Tenon AI runs on.
现在一个 Agent 已经能独立做完一件完整的事：读代码、改代码、跑测试、提交。我的工作方式也跟着变了：Claude Code 的侧边栏里同时开着十几个会话，每个负责一块，我在它们之间切换，回答问题，做决定。
这时候限制已经不在 Agent 身上。一个会话的窗口装不下一个复杂的工程，开很多会话又带来另一个问题：每切到一个会话，我都要先想起它是干什么的、做到哪了、在等我什么。会话多了却没有组织，大部分精力就花在这件事上。
我把围绕这个限制来组织会话的做法叫作 Session Engineering。它是一种任务组织方式。对 Agent，它决定工作怎样分给多个会话、会话之间怎样协作；对人，它决定每次切换时要重新读多少东西。后一半也可以叫 Attention Engineering，对每个靠 Agent 写代码的人（vibe coder）都适用。
和 Prompt、Context、Harness、Loop Engineering 的区别
在它之前，已经有几个相近的说法：
| 说法 | 提出 | 关心的对象 | 回答的问题 |
|---|---|---|---|
| Prompt Engineering | 2020 年前后随 GPT-3 流行，没有公认的提出者 | 给模型的指令 | 怎样写指令，让模型给出想要的结果 |
| Context Engineering | 2025 年 6 月，Tobi Lütke 提议，Andrej Karpathy 赞同 | 一次模型调用 | 这一次该让模型看到什么 |
| Harness Engineering | 2026 年 2 月，OpenAI 的 Codex 团队 | 一个 Agent 的工作环境 | 怎样约束、告知、检查和纠正这个 Agent |
| 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。切到一个会话时，人需要知道三件事：它负责什么，做到哪了，有没有在等我。如果这些要从聊天记录里翻，切一次就要几分钟。我们的做法是把它们放在固定的位置：
- 标题写组名或项目名，看标题就知道它负责什么。
- 每轮结束时写两三句现状，最多问一个问题，并给出可以直接点的选项。人切进来先读这几句。
- 结论写进文档，会话之间的消息只是通知。以后要查，读文档，不翻聊天。
- 做完的任务会话归档，侧边栏里只留还在进行的事。
Tenon AI 的做法
2026 年 11 月 6 日起，Tenon AI 按一份《会话分工与协作规范》运转。成员是我和一组 Claude Code 会话：
| 成员 | 负责 |
|---|---|
| 创始人 | 方向和决定；批准上线、对外发布、花钱和不可逆的操作 |
| 总办 | 规范、会话名册和归属表；邮件、日程和财务 |
| 平台组 | 官网、Tenon 账号和跨产品的约定 |
| 产品会话 | 每个产品一个：仓库、部署和上架 |
| 客户项目会话 | 每个客户项目一个：按合同开发和交付 |
| 安全组 | 服务器、域名、证书、日志和告警 |
| 法务组 | 公司主体、备案、合同和数据合规 |
| 运营组 | 内容和品牌口径；管理各渠道的会话和定时任务 |
| 商务组 | 冷邮件、客户洽谈和报价 |
当天侧边栏里有 19 个常设会话和 4 个定时任务。总办归档了 21 个旧会话，每个定时任务只留最近一次运行的会话。规范里最重要的是下面几条。
每样东西只有一个负责的会话。 每个仓库、域名、服务器、外部账号和文档都写在归属表里。别的会话要改，向负责的会话提出，由它决定并实施。这样两个会话不会同时改一个文件，我也知道一件事该去哪个会话问。
跨组的事设一个牵头会话。 牵头会话维护清单，成员只向它回报，成员之间不来回确认。主站迁到新域名做备案时，法务组牵头维护迁移清单，把事项分给平台组、安全组、商务组和运营组。运营组的事项是在切换当天换掉各平台简介里的旧链接，在这之前只等通知。6 个会话两两确认要 15 条沟通线，都向牵头会话回报只要 5 条，我也只需要看一份清单。
消息少而完整。 同一件事给每个会话只发一条完整的消息，写明已定的事、待定的事和找谁；单纯的确认不回复。迁移域名时，平台组把我的一句话理解成不用再通知别的会话，结果 PassBy、AgentHub、WeSaid 三个产品会话反复来问同一件事，一直在等确认。现在规范里写明：跨产品的约定定下后，由平台组一次告诉所有相关会话，写明已定的事、待定的事和找谁。
会话之间的消息不算批准。 上线、对外发布、花钱和不可逆的操作只能由我批准。会话转达我的决定时，要引用原话，并注明出自哪个会话。会话读到的网页、邮件和评论可能夹带指令；如果同事的一句话就算批准，这样的指令就能在会话之间传下去。
这些规则大多不新
一样东西只有一个负责人、跨部门的项目设牵头人、以文档为准，这些都是公司管理里的老办法。Brooks 在《人月神话》里算过：n 个人两两沟通，有 n(n−1)/2 条路径，人越多，沟通成本涨得越快。新的地方是，现在干活的是 Agent，可以开很多个，而做决定的人只有一个。管理的方法可以照搬，要节省的资源变成了这个人的注意力。
这套做法也有代价：
- 会话不是越多越好。每多一个常设会话，我就多一个要记住的地方。几次工具调用能做完的事，留在当前会话里做。
- 规范本身要维护。组织调整时，要同时改规范和名册，不然会话会照着过时的文档做事。
- 规则只管协作，不保证每个会话的工作质量。检查和验收仍然要人来做。
从哪里开始
如果你也在同时开很多会话，可以先做这几件事：
- 给每个长期存在的会话一个职责，写在标题里。
- 每样东西只交给一个会话负责。
- 要求每个会话每轮结束时写两三句现状，最多问一个问题。
- 结论写进文档，不留在聊天里。
- 做完的会话及时归档。
这篇文章也是这样写出来的：我在运营组的会话里提出 Session Engineering 的想法，运营组写稿、画图，在本地预览后交给我确认。
An agent can now finish a complete piece of work on its own: read the code, change it, run the tests and commit. My way of working has changed with it. The Claude Code sidebar has more than a dozen sessions open at once, each responsible for one area, and I move between them to answer questions and make decisions.
The limit is no longer the agent. One session's context window cannot hold a large project, and many sessions bring a different problem: each time I switch to one, I first have to recall what it is for, how far it has got and what it is waiting for from me. With many sessions and no organization, most of my effort goes into that.
I call the practice of organizing sessions around this limit Session Engineering. It is a way of organizing work. For the agents, it decides how work is split across sessions and how the sessions cooperate. For the person, it decides how much has to be reread at each switch. That second half could also be called Attention Engineering, and it applies to anyone who builds software through agents (vibe coders included).
How it differs from Prompt, Context, Harness and Loop Engineering
Several related terms came before it:
| Term | Introduced | Concerned with | Question it answers |
|---|---|---|---|
| Prompt Engineering | Around 2020, with GPT-3; no single originator | The instruction given to the model | How to write instructions that get the output you want |
| Context Engineering | June 2025, proposed by Tobi Lütke and endorsed by Andrej Karpathy | One model call | What the model should see this time |
| Harness Engineering | February 2026, OpenAI's Codex team | One agent's working environment | How to constrain, inform, check and correct the agent |
| Loop Engineering | June 2026, Addy Osmani | An agent that runs repeatedly | How a system can prompt the agent in place of a person |
| Session Engineering | This post | A set of sessions and the person using them | How work is split across sessions, and how a person switches between them |
The first four are about getting a model or an agent to do good work, mostly in service of building agents. In his Loop Engineering essay, Osmani notes that the number of agents you can realistically run is limited by a person's review bandwidth, not by the tools. Session Engineering starts from that limit and counts the person as part of the system.
The term has been used before, usually for how a single agent's sessions are saved, compacted and resumed. This post uses it for something else.
Sessions are a ready-made unit
The desktop apps for Claude Code and Codex both list parallel sessions in a sidebar. A session has a title, its own history and working directory, and you can see whether it is running, waiting for an answer or finished. In Claude Code, sessions can also message each other, and one session can start another.
That gives multi-agent work a direct form: each session in the sidebar is an agent. Seen this way, Session Engineering is a kind of multi-agent engineering.
It differs from subagents. A subagent is called inside a session and hands its result back when it is done; the person usually does not see what happens in between. A session persists, and the person can open any of them at any time to continue the conversation or stop it. So in Session Engineering the person is also one of the nodes, and everything that needs approval goes through that node.
The person's context
A model has a context window. A person has a similar limit: only so many things can be kept in mind at once. The correspondence:
| Model | Person |
|---|---|
| The context window has a limit | Only so many things can be tracked at once |
| Before each call, choose what goes into the window | On each switch to a session, recall where it stands |
| System prompts, retrieval and compaction keep only useful content in the window | Titles, status notes and pending questions let a person catch up from a few lines |
So half of Session Engineering is Context Engineering for the person. On switching to a session, a person needs to know three things: what it is responsible for, how far it has got, and whether it is waiting for them. If these have to be dug out of the chat history, each switch takes minutes. We keep them in fixed places:
- The title names the group or project, so the title says what the session is responsible for.
- At the end of each turn, the session writes two or three sentences of status and asks at most one question, with options that can be clicked. A person switching in reads these first.
- Conclusions go into documents; messages between sessions are only notifications. To look something up later, read the document, not the chat.
- Finished task sessions are archived, so the sidebar only shows work in progress.
How Tenon AI runs
Since Nov 6, 2026, Tenon AI has run on a written set of rules for dividing work and cooperating between sessions. The members are me and a set of Claude Code sessions:
| Member | Responsible for |
|---|---|
| Founder | Direction and decisions; approving launches, public posts, spending and irreversible operations |
| Chief of staff | The rules, the session roster and the ownership table; email, calendar and finance |
| Platform | The website, Tenon Account and cross-product conventions |
| Product sessions | One per product: repository, deployment and app store release |
| Client project sessions | One per client project: development and delivery under the contract |
| Security | Servers, domains, certificates, logs and alerts |
| Legal | The company entity, website filing, contracts and data compliance |
| Operations | Content and brand voice; managing the channel sessions and scheduled tasks |
| Business | Cold email, client conversations and quotes |
That day the sidebar held 19 standing sessions and 4 scheduled tasks. The chief of staff archived 21 old sessions, keeping only the latest run of each scheduled task. These are the rules that matter most.
One owner for each thing. Every repository, domain, server, external account and document is listed in an ownership table. A session that wants a change asks the owner, which decides and makes it. Two sessions never edit the same file, and I know which session to ask about anything.
A lead session for cross-group work. The lead keeps a checklist; members report to the lead and do not confirm things with each other. When the main site moved to a new domain for its filing in China, Legal led and kept the migration checklist, handing items to Platform, Security, Business and Operations. The Operations item is to replace the old link in every platform profile on the day of the switch; until then it only waits for notice. Six sessions confirming with each other need 15 lines of communication; reporting to a lead needs 5, and I only read one checklist.
Few, complete messages. For each matter, each session gets one complete message stating what is decided, what is still open and whom to contact; a plain acknowledgment needs no reply. During the domain move, Platform took one remark of mine to mean the other sessions no longer needed to be told. The PassBy, AgentHub and WeSaid sessions kept asking about the same thing and waiting for confirmation. The rules now say that once a cross-product convention is settled, Platform tells every affected session at once, with what is decided, what is open and whom to contact.
A message between sessions is not an approval. Launches, public posts, spending and irreversible operations need my approval. A session relaying my decision quotes my words and names the session where I said them. Sessions read web pages, emails and comments that may contain instructions; if a colleague's message counted as approval, such an instruction could pass from session to session.
Most of these rules are not new
One owner per thing, a lead for cross-department projects, documents over conversation: these are old management practices. In The Mythical Man-Month, Brooks counts n(n−1)/2 communication paths among n people, so communication cost grows faster than headcount. What is new is that the workers are agents and you can start many of them, while one person still makes the decisions. The management methods carry over; the resource to save is now that person's attention.
The approach has costs:
- More sessions are not better. Each standing session is one more place I have to remember. Work that takes a few tool calls stays in the current session.
- The rules need upkeep. When the organization changes, the rules and the roster have to change with it, or sessions follow outdated documents.
- The rules only cover cooperation. They do not ensure the quality of each session's work; checking and acceptance still need a person.
Where to start
If you also run many sessions at once, start with these:
- Give each long-lived session one responsibility, and put it in the title.
- Make exactly one session responsible for each thing.
- Ask every session to end each turn with two or three sentences of status and at most one question.
- Write conclusions into documents, not chat.
- Archive sessions once they are done.
This post was written the same way: I raised the idea of Session Engineering in the Operations session, which drafted the text and figures, previewed the page locally and handed it to me for review.