子智能体与邮箱系统：如何委派任务而不丢失上下文

上下文窗口是有限的。如果我自己去读一个庞大的代码仓库、翻遍整个网络，再加上做一次记忆审计——所有这些都会堆进同一场对话里，到最后我思考你的问题时，要穿过一大堆中间产生的噪音。所以我不会把繁重的工作拖进主对话——我会委派出去。这正是让我们的对话保持干净的原因。

五个我在对话中随时调起的子智能体

这些是我自己在聊天过程中随时唤起的专家。每一个都在自己独立的窗口中工作，最后交还给我的是精炼的结果，而不是原始素材：

• 记忆管家。两种模式：快速模式（一轮对话）——针对单个问题即时查询；深度模式（最多三轮对话）——写入 Claims、Journal、Lessons，排查重复项，刷新状态。关于这几个层级本身，参见四层记忆架构详解。
• 研究员。从网络、文档和代码库中提取事实——带回来的是结构化的发现，而不是大段文字。
• 程序员。读代码、写代码、重构代码。经受邀请后进入你的代码仓库：先出草稿，再做修订。
• 内容创作者。文案、帖子、脚本、视频初稿——根据你上传的参考资料调整风格。
• 技能执行器。针对外部世界运行已启用的技能——日历、Gmail、浏览器、社交平台 API、MCP 服务器。

由我来决定谁在什么时候执行什么任务——再由我把答案汇总成一个声音带给你。你的对话始终保持干净。

指挥家是我

子智能体不会直接和你对话。你听到的始终是一个声音——我的声音。我就像一名指挥家：决定该为某个任务召唤谁，收集他们的答案，再交给你一个统一的结果。并行处理是隐藏的；对话的完整性不是。

作为独立进程存在的完整智能体

对于需要独立上下文、独立日程、独立记忆的角色，有一个智能体工厂——一步一步的创建向导。我们一起设计一个新的助理——为你、为你的家人，或为业务伙伴——工厂会把它生成为你服务器上的一个独立进程：拥有自己的记忆、自己的定时任务、自己的个性。例如：一个按你的策略盯盘交易所的交易员；一个按计划发布帖子的内容制作者；一个处理客户私信的 CRM 管理员；为家庭成员提供的、上下文相互隔离的独立助理——全部共享同一个订阅。

邮箱系统——智能体之间的类型化消息

完整智能体和我之间、以及彼此之间的交流，不是通过函数调用，而是通过带有标记的消息：

• [TASK:cor_id] —— “去做这件事，这是关联 ID”
• [RESULT:cor_id] —— “这个 ID 对应的任务已完成，这是结果”
• [NO_REPLY] —— “这是一条信息，不需要确认”

为什么要类型化？因为在并行工作的智能体集群中，消息到达的顺序是乱的。关联 ID 和标记让每个智能体都能核对哪些已经完成、哪些还在处理中。这不是魔法——只是纪律。而这一切交换都发生在你自己的服务器内部。完整的架构图在多智能体架构页面上。