腾讯自托管AI助手新特性:由不同性格的专家组队协作

Octop 是腾讯云开源的自托管 AI 助手。它可以部署在自己的电脑、服务器或 NAS 上，支持多用户使用。装好之后，既能在网页里聊天，也能把助手接到飞书、企业微信、钉钉、微信等日常使用的聊天工具里。

在 Octop 中，和用户对话的助手被称为「专家」。你可以为不同工作创建不同专家：一位负责研究，一位负责写作，一位负责审代码。每位专家可以配置自己的模型、工作区、记忆和工具，也可以读取知识库、通过连接器操作应用，或执行定时任务。对话记录、凭据和工作区默认保存在部署机器上；如果使用云端模型，相关输入仍会发送给对应的模型服务。

2026 年 10 月 18 日发布的 1.0.2，最值得关注的更新是专家团队：多位专家可以围绕同一项任务分工，由主持人安排工作、汇总结果。同时，云端协同让用户能从本机使用另一台 Octop 上的专家和团队。

这两项更新让 Octop 的使用方式发生了变化。过去可以分别找几位专家办事，现在可以把一项需要研究、方案和评审的工作交给一个团队，不必自己在几个对话窗口之间搬运材料。

要让几位专家真正合作，先得看清一位专家怎样工作、能做什么、记得什么。1.0.2 在这些基础环节上也做了补充：Ask、Plan、Craft 三种对话模式，可手工维护的专家记忆，以及各自独立授权的性格、子智能体和工具。

多专家本来就是 Octop 的基础能力。1.0.2 新增的团队，建立在这些独立专家之上。

一位专家适合负责一类相对固定的工作。创建时，可以从内置专家或专家市场选择模板，也可以自己写工作说明。模板规定它以什么角色处理问题；模型、知识库、技能和连接器，则决定它能用哪些资料和工具。

例如，准备发布一款新产品，可以分别配置三位专家：

研究专家负责查阅市场资料、整理竞品信息，挂上研究所需的知识库和检索工具；产品专家负责需求、功能优先级和实施方案，读取项目文档；评审专家负责检查方案中的假设、风险和遗漏，使用相应的评审说明。

三位专家各有自己的工作区和对话记录。研究专家不必在每次任务中重新学习产品专家的工作要求，产品专家也不需要同时承担所有评审职责。之后仍可以单独找其中任何一位聊天。

1.0.2 还增加了业务流程、知识工作等专家模板，覆盖 SOP、操作手册、研究流程等场景，方便从已有配置开始，而不必从空白提示词写起。

不过，有三位专家，并不等于它们已经能够一起完成工作。用户分别提问、复制回复、再整理成稿，协调工作依然落在自己身上。专家团队解决的就是这一步。

选好岗位和工具之后，还需要决定这次任务是否允许专家实际操作。Octop 提供三种对话模式，它们限制的是执行范围，不是回答长短，也不是模型的思考强度。

Ask：先了解情况，不修改文件

Ask 是只读的问答模式。专家可以读取工作区文件、检索知识库、联网查资料，但不能创建或修改文件、执行命令，也不能调用技能和连接器。

例如，先问产品专家：“根据现有项目资料，发布前还有哪些问题没有解决？”它可以查阅材料、给出分析，但不会顺手改掉项目文档。只想获得判断、不希望它实际操作时，选 Ask 就够了。

Plan：把步骤写下来，等确认后再执行

Plan 在只读查阅的基础上，允许专家把计划保存为工作区中的 plans/*.md 文件。它可以创建或修改这个计划文件，但不能改其他文件、运行命令或调用技能和连接器。写完计划后，会停下来等待用户确认。

接着可以问：“根据这些问题，先列一份发布准备计划，写清每一步要做什么、需要哪些材料。”得到的是一份可以查看和修改的计划，而不是已经执行的工作。

确认计划后，再切换到 Craft 执行。对于已有待执行计划的对话，也可以用“按计划执行”或“开始干”等指令进入执行阶段。

Craft：使用已授权的工具，把任务做完

Craft 是动手模式。专家可以在已有权限范围内写文件、运行命令，调用已启用的技能和连接器，把任务落实到工作区或相关应用中。

例如，确认发布准备计划后，让产品专家按计划整理材料、生成发布文档，涉及应用操作时再使用对应连接器。能否完成某项操作，仍取决于是否配置了所需工具、是否获得授权，以及是否需要审批；选择 Craft 不会绕过这些限制。

三种模式可以按需要切换，并不要求每次都依次走一遍。直接查询资料可以用 Ask，任务明确时也可以直接用 Craft；拿不准执行步骤时，先用 Plan 看过计划再动手。

创建或编辑专家时，可以设置默认模式，未设置时缺省为 Craft。新建对话，以及没有单独保留模式的即时通讯、命令行和定时任务线程，会按专家默认值运行；已经开过的对话则保留自己的模式选择，不会因为改了默认设置就一起切换。

单独使用专家时，这三种模式让用户能够控制它什么时候执行。如果任务还需要研究、方案和评审几种专业分工，接下来要解决的就是协作：不能只让用户分别提问、复制回复，再自己整理成稿。

创建团队时，需要选择一位主持人使用的模型，并加入至少两位普通专家作为成员。成员可以是自己的专家，也可以是同一实例里其他用户共享给自己的专家。

仍以产品发布为例。用户在团队里提出：“根据现有项目资料，准备一份发布方案，并检查其中的主要风险。”消息会先交给主持人。

主持人把需求整理成具体任务

主持人会先理解用户的要求，再改写成适合各位成员的任务说明。例如，请研究专家补充竞品依据，请产品专家制定发布方案，请评审专家检查风险。

这里的重点是改写后派工。成员收到的是与自己职责相关的工作要求，而不是每个人都收到同一句话、各自写一遍完整方案。需要时，主持人可以同时向多位成员派工。

主持人的配置也与普通专家不同。它主要负责协调，使用成员查询、派工、记忆和时间等工具，不挂普通专家用于实际工作的技能、插件和连接器。具体研究、写作或文件操作由成员完成。

成员的工作过程不藏在主持人的回复里

成员的回复会直接出现在团队聊天的同一条时间线上，带着各自的身份。用户能看到研究专家提供了什么依据、产品专家提出了什么方案、评审专家指出了哪些问题。

成员完成任务后，系统会再次交由主持人处理。主持人据此总结结果，判断是否还需要补充工作。

这比只有一份合并后的答案更便于核对：如果竞品资料不充分，可以继续追问研究部分；如果方案与评审意见不一致，也能看到分歧来自哪里，而不必猜测一段最终结论是怎样得出的。

在聊天软件里也能用团队

团队的即时通讯通道绑定在主持人上，但成员回复也会同步到这条通道。派工后会有提示，成员完成后会发送带姓名的回复，最后再由主持人总结。

因此，团队不只在网页控制台里可用。绑定飞书或钉钉之后，同样可以在那里提出任务、接收各位专家的结果。

团队成员仍然是独立专家：保留自己的工作区，也可以单独聊天、加入多个团队。加入团队不会把几位专家合并成一个共用所有资料的助手。

目前专家团队仍处于 Beta 阶段。首版团队只供创建者使用，不支持团队嵌套；成员必须是本机普通专家，不能把另一台 Octop 上的专家直接加入本机团队。有未完成派工的成员，也不能被移出或删除。

专家在另一台机器上，也可以直接使用

与专家团队同时值得关注的，是 1.0.2 的云端协同。连接另一台 Octop 后，对端的专家和团队会出现在本机对话侧栏的「云端」中。用户可以直接发起聊天，也可以读写对端专家工作区里的文件，对话记录仍留在专家所在的机器上。

例如，公司服务器上已经配置了一组研究专家，在自己的电脑上连接后，就可以使用它们，不必重新搭建一份。这里的「云端」指连接另一台 Octop 实例，并不要求它一定部署在腾讯云。

云端协同目前同样带有 Beta 标记。它提供的是远程使用入口，不会把两端资源全部合并。虽然不能跨实例混编本机团队，但可以直接使用对端已经建好的团队。

团队解决了几位专家如何合作的问题，但每位成员怎样工作、怎样表达，仍由它自己的配置决定。其中，专家模板和性格是分开设置的。

模板规定岗位要求，性格影响回答方式和沟通习惯。产品经理模板用于处理需求、优先级和产品取舍；同一模板配上不同性格，表达方式可以不同。

Octop 在「个性化 → MBTI」中提供 16 种性格，按分析家、外交家、守护者、探险家分组。拿不准时，也可以通过「测一测」获得推荐。以产品专家为例，几种常见预设的表达倾向是：

如果更希望产品专家明确指出优先级和取舍，可以选择偏直接的表达方式；如果希望它帮助拓展方案，则可以选择偏发散的方式。不选择 MBTI 时，专家使用默认的中性口气，也可以只写自己的系统提示。

这些性格预设通过系统提示影响回答、规划和处理分歧等习惯，并不代表模型真的具备人的人格，更不会增加专业知识或工具权限。需要它做产品工作，仍要有相应的岗位说明和资料；是否能修改文档、调用应用，仍由工具与授权决定。

在团队中，成员继续使用各自的性格。研究专家可以偏重结构和证据，产品专家可以更直接地讨论取舍，评审专家可以逐项核对。主持人则使用专门的协调配置，创建团队时没有普通专家的 MBTI 选择项。

1.0.2 对个性化权限的拆分，也让性格可以单独授权。管理员可以允许用户调整表达方式，而不必同时开放工具、插件或记忆设置。

给不同工作创建专家很方便，但一位专家的任务内部，也可能需要几种专业能力。产品专家写发布方案时，可能要补一段用户研究、检查一组指标，或请人从技术角度评估一个功能。为了这些阶段性任务，每次都新建一位完整专家，未必必要。Octop 的子智能体适合处理这种情况。

子智能体以岗位说明的形式挂在当前专家下。随包提供的中文库有 272 份定义，分布在 19 个领域：工程、设计、产品、金融、安全、测试、人力资源、法务、供应链等。定义中通常包含身份、工作流程、规则和交付要求，不只是角色名称，而是执行子任务时可以依据的具体说明。

专家在处理任务时，可以把某一部分交给已配置的子智能体，获得结果后再继续自己的工作。用户仍然与原来的专家对话。

子智能体与团队成员，区别在哪里

区别在于，团队成员是独立专家，子智能体是在当前专家内部被调用的执行角色。

因此，如果希望评审角色长期保留自己的项目记录、单独接收消息，就应创建评审专家；如果只是让产品专家在写作过程中做一次专项检查，配置相应子智能体更合适。

独立专家之间也不一定要组建团队。输入框中的 @，或专家调用的 ask_agent，可以向另一位正在运行的专家请求协助。这仍然是在调用另一位独立专家，与调用内部子智能体是两回事。需要多位成员共同参与、在同一个房间呈现结果时，再使用团队。

子智能体也有沟通风格，会覆盖专家的性格吗

子智能体的岗位说明里也可能包含「沟通风格」。例如，评审角色要求结论明确、证据充分；招聘角色要求按指定格式输出岗位描述。这些要求影响的是子智能体交回的内容，它不会因此取得当前专家的对外身份，也不会自动把专家的 MBTI 设置换掉。

假设产品专家选择了 ENFP，又调用一位强调逐项检查的子智能体：检查结果可以严谨、简洁，产品专家拿到结果后，仍会按自己的表达习惯说明问题、调整方案。如果它原样引用检查结论，被引用的部分会保留原有措辞，不能把最终回复理解为所有文字都由同一种性格重写。

这样，用户可以给专家选一个适合日常交流的性格，同时为专项任务保留不同的工作要求。

角色和分工配置好之后，长期使用还会遇到另一个问题：每次新开对话，都要重新说明自己的身份、偏好和工作要求吗？Octop 的专家记忆用于跨对话保留这些信息。它与当前聊天记录不同，也不是上传到知识库里的项目资料。项目方案可以放进知识库，而“我负责产品决策”“汇报先给结论”“未经确认不要修改正式文档”，更适合成为这位专家长期参考的要求。

记忆按专家维护。产品专家可以保留产品工作的偏好，研究专家可以保留资料筛选的要求，不会因为属于同一个账号，就自动把几位专家的记忆合在一起。

用户档案与强记忆，可以直接编辑

1.0.2 在「个性化 → 记忆」中提供了两个手动编辑入口。

用户档案对应 USER.md，适合记录称呼、身份、职责和个人偏好。例如，告诉产品专家自己负责哪个业务、通常面向谁汇报，以及希望采用什么表达方式。

强记忆对应 MEMORY.md，适合写入需要持续遵守的固定要求。例如，发布方案必须区分已确认事实与待验证假设，引用外部资料时要保留出处。这些内容由用户直接维护，专家可以读取，但其文件工具不能自动改写这两份文档。

聊天中说“记住这件事”，走的则是普通记忆保存机制，内容写入 octop-memory，不再自动改写 MEMORY.md。如果希望一条要求明确出现在自己维护的固定文档里，应直接编辑用户档案或强记忆。

有冲突先审核，手写要求优先

手动文档与普通记忆之间出现明确冲突时，Octop 会优先采用用户维护的文档，并把冲突内容转成待审核候选，而不是直接覆盖。

例如，用户档案写着“汇报先给结论”，普通记忆中却出现“用户希望先展开背景”，检查识别出冲突后，会提示用户处理。要求究竟有没有改变，由用户判断，不让系统仅凭一次对话就更新长期偏好。

这里还有一个使用细节：USER.md 和 MEMORY.md 在每个会话首次加载时形成全文快照，之后沿用这份快照。修改文档会对新会话生效，已经进行中的会话不会立即换成新内容。更新了重要要求后，新开对话更稳妥。

团队成员各有记忆，团队要求由主持人传达

加入团队不会让成员的记忆自动共享。每位成员仍使用自己的配置与记忆；团队准则和团体记忆保留在主持人一侧，需要成员遵守时，由主持人写进派工消息。

例如，团队要求这次发布方案统一使用某种口径，主持人需要把要求明确交给成员，不能假定所有成员都已经读取了主持人的记忆。这也与子智能体不同：子智能体没有一套独立专家式的长期记忆，相关背景要随子任务传入。

1.0.2 同时支持当前专家记忆的备份与恢复。持续积累的偏好和要求可以备份，不必等到迁移或维护时再重新整理。

把这些能力放在一起，Octop 1.0.2 的重点就清楚了：它没有改变「专家」是什么，而是补上了专家工作的几个环节。任务开始前，可以用 Ask 或 Plan 看清情况；需要动手时，用 Craft 在权限内执行；多位专家协作时，由主持人改写任务、汇总结果；每位成员还可以有自己的性格、子智能体和记忆。

回到产品发布的例子：研究专家补充竞品依据，产品专家制定方案，评审专家检查风险。用户不必逐个转发任务、复制回复，仍然能看到各位成员的依据和意见，再决定下一步怎么做。需要跨机器使用已有专家时，也不必重新搭建一套。

专家团队和云端协同目前都还是 Beta。首版团队不共享、不能嵌套，成员必须是本机专家；云端协同也只提供远程使用入口，不合并两端资源。这些限制说明它们仍在完善，但已经能覆盖一类真实工作：一件需要多种专业判断、又需要统一收口的事。