四、协作与自动化

适用版本：LobeHub 2.2.20（自建版） 本篇目标：把「每次都要重新交代一遍」变成「一次配置、长期复用」——助手、群聊、任务、定时、API、看板。

4.1 智能体

什么时候用：同一类任务反复做，想固化成一个「专属助手」。

4.1.1 内置助手

每个账号进来就带一批内置助手，实测每个账号 24–25 个，按主题分组：

📚 科研与学术专家团队
🛠️ 工程与架构专家
🎨 视觉与交互设计
💼 高管决策智囊
📊 办公与内容运营
🏛️ 公文政务与标书方案
✍️ 论文专著与深度研究

每个助手是一套「人设 + 默认模型 + 绑定技能」。点进去直接用，不用配置。

左侧的助手分组。每个 emoji 标题是一组，点开能看到该组下的所有助手。

4.1.2 自建助手

三步：

1. 在「助理」区点「添加助理」。
2. 填三样东西：
   • 系统提示词：它是谁、怎么说话、遵守什么规则。
   • 默认模型：这个助手默认用哪个模型。
   • 技能绑定：它能用哪些技能。
3. 保存，它会出现在助手列表里。

系统提示词的写法有个简单公式：

你是【角色】。
你的任务是【具体任务】。
你的输出必须满足：【格式/风格/长度约束】。
你不应该做：【禁止事项】。

可复制示例（投稿信助手）

你是资深 SCI 论文投稿顾问，服务对象是临床医学研究者。
你的任务是根据我提供的论文摘要和目标期刊，起草一封投稿信（cover letter）。
输出必须满足：
- 英文，300 词以内；
- 结构：致编辑 → 研究价值 → 与期刊契合点 → 声明（未一稿多投、全体作者同意）；
- 不使用夸张形容词，不承诺研究意义之外的东西。
你不应该做：不要编造我没提供的数据或作者信息。

4.1.3 社区市场

「社区」页是助手市场，能看到别人公开的助手。点进去看人设和技能，觉得合适就「添加到我的助手」。

注意：社区助手是别人写的提示词，可能夹带特定倾向或引导。用于正式工作前，先读一遍它的人设，必要时改掉不合适的部分。

验证：新建一个助手，保存后在列表里能找到它，点进去发一句话能正常回复。

4.2 群聊多智能体

什么时候用：一个任务需要多个视角——写作 + 审稿 + 统计——你想让它们在同一处对话。

4.2.1 建群与拉人

实测路径和很多教程不一样：没有「手动添加成员」这一步。你只描述这个群要干什么，系统自己组队。

1. 左侧「助理」分组标题右侧点添加按钮，菜单里选「创建群组」。
2. 弹窗问「这个群组要做什么？」，直接写用途，例如：

组建论文三方评审小组：方法学审稿人负责统计与研究设计，
临床审稿人负责医学意义，写作编辑负责语言与投稿规范。
三人针对同一篇摘要各自给出可执行的修改意见。

3. 提交后「群组构建专家」先产出一份工作规范，再调用「批量创建 Agent」，此处弹出 「1. 批准 / 2. 告诉 Agent 你希望它怎么做」+ 提交。
4. 批准，等它建完。回到群聊页，侧栏「成员」变成 4：1 位 Supervisor + 3 位参与方。

实测数据：从提交到建群完成约 2 分钟，成员名单、分工、交接规则全部按你那段描述生成。

「这个群组要做什么？」是建群的唯一输入，下面六张卡是可选模板。

这一步不批准，群就永远是空的。

Supervisor、方法学审稿人、临床审稿人、写作编辑。

真实三方评审：方法学审稿人指出 118 例中仅 21 例阳性事件的过拟合风险；临床审稿人抓住「免除二次腋窝清扫」的结论越级；写作编辑要求按 IMRAD 重构摘要。最后由 Supervisor 汇总成分优先级清单。

多方接力的过程看动图：/upload/guide/shots/gif/P4-gif-04-group.gif

群聊窗口。注意每条回复前面的头像——不同的助手在同一个话题里发言。

4.2.2 谁先说话、怎么控场

群聊里默认由系统决定谁接话。想指定，就在消息里点名：

@写作助手 先给一版重写稿；
@审稿助手 再按 Nature 审稿标准挑三个最严重的问题；
@统计助手 最后检查方法部分有没有统计学错误。

控场三条经验：

• 一次只让一个角色输出，否则几段回答会互相覆盖重点。
• 给顺序，不要让它们同时开口。
• 最后自己收口，让某一个助手做汇总，而不是你手动拼。

4.2.3 什么时候值得用群聊

4.3 模式选型：对话流 Agent 模式 vs 看板任务模式

什么时候用：在日常聊天框里就能让助手调技能干活，为什么还要去左侧导航的「任务」建卡片？弄清两者的边界，能帮你省下大量 Token，并让成果清晰沉淀。

4.3.1 本质区别与运行机制

4.3.2 怎么选（决策口诀与场景对照）

• 选对话流 Agent 模式（直接在聊天框里做）：
  • 探索型与试探型任务：需求尚不确定，需要根据模型返回的第一步结果临场调整思路。
  • 高频即时调试：如写一段代码、查一个报错、即时润色几句话，需要立刻追问两句。
  • 需要逐步批准的敏感操作：例如复杂的脚本沙箱执行，希望每一步由人点「批准」再往下走。
• 选任务模式（去左侧任务看板建卡片）：
  • 目标明确的阶段性交付件：如“整理本周前哨淋巴结影像组学文献生成 P0-P2 修改清单”、“根据 5 篇参考材料起草结构化报告”。
  • 不想污染日常对话上下文：希望保持某个专用助手的对话流干净，不想让庞大的中间分析日志把历史撑爆。
  • 周期性自动跑的作业：所有需要每天/每周自动执行的监控、爬取、报告任务，必须先走任务模式或定时任务。
  • 团队分工或多角色工单化流转：一人提需求创建卡片，指派给特定专家 Agent，等候产出后点击确认审阅。

最佳协同实践： 先在对话流里与 Agent 试探推导，理顺思路与提示词 → 需求稳定后，将其固化为任务看板中的卡片（或挂接为定时任务）长期稳定交付。

4.4 任务看板实操

什么时候用：任务多，想看着它们跑，而不是每次都手动问。

4.4.1 建任务、指派

1. 进「任务」页，点右上角的「+」。
2. 页面顶部展开一行表单：只有一个 添加描述… 输入框，没有独立标题栏。写清「做什么 + 交付什么」即可，标题它会自己取。
3. 点表单里的「助理」芯片，展开指派面板（第一项是「未分配」，往下是你全部助手），选中一个。
4. 点「创建任务」。看板立刻多出一张卡，编号按 T-1 / T-2 … 递增。

描述填进去后，右下角「创建任务」才可点。

「未分配」在列表最上方。别跳过指派，没指派的任务没人跑。

4.4.2 看执行过程与产物

任务详情页顶部有「运行」按钮，点它才真正执行。状态依次走「待办 → 运行 → 待审阅」，跑完活动区多出一条运行记录（形如 三方评审修改意见分级执行清单 #1 · 11s），点开就是正文产物。同一任务可反复点「运行」，每次追加一条 #n。

跑完后的真实样子：状态已是「待审阅」，活动区多出一条 三方评审修改意见分级执行清单 #1 · 11s 的运行记录，上面还留着「示例用户 创建了任务 · 4 分钟前」。点这条 #1 就是产物正文。

实测产物：P0 / P1 / P2 三级执行清单，每条标注意见来源（方法学 / 临床 / 写作编辑），照着改稿即可。

动图版（创建 → 指派 → 运行 → 产出）：/upload/guide/shots/gif/P4-gif-05-task.gif

实测修正：早先「任务只是待办、不会自动产出、得回助手对话里做」的说法不成立。任务本身就是可执行单元，点「运行」就出结果；区别只是不会自己开始，需要你点一下，或者交给定时任务按期触发。

4.4.3 失败怎么排查

实测到的真实状态链是 待办 → 运行 → 待审阅，界面上没有「失败」这个标签。跑坏了的表现是产物内容不对或运行记录缺失，处理方式见上表。

4.5 定时任务

什么时候用：想让它每天/每周自动干一件事。

4.5.1 设周期任务

定时任务在「任务」页的定时标签下。新建时要填：

• 执行内容：具体要它做什么（越具体越稳）。
• 周期：每天 / 每周 / 自定义 cron。
• 使用助手与模型：建议固定，不要用「默认」，否则模型换了行为会变。

实测提醒：定时任务列表默认是空的，需要通过对话触发创建，或在任务页手动新建。第一次配完，建议先设成「每天一次」跑两天看稳定性，再改成你真正想要的频率。

「任务」与「定时任务」是同一页的两个标签。列表为空是初始状态，不是功能坏了。

4.5.2 失败在哪看原因

任务详情页有「执行历史」，每次执行都有状态和日志。失败时点开看：

• 是模型报错（换模型）
• 是超时（拆小任务）
• 是提示词没给够信息（补上下文）

4.5.3 成本与频率控制

定时任务是最容易烧钱的功能，因为它不需要你在场。

三条纪律：

1. 先低频试运行，稳定后再提高频率。
2. 任务里限定输出长度（「不超过 500 字」），否则每次都可能写一大篇。
3. 定期看执行历史，发现连续失败先停掉，别让它空跑。

可复制示例

每周一 09:00 执行：
检索过去 7 天「乳腺癌 前哨淋巴结 影像组学」相关的新论文，
筛出 5 篇最相关的，每篇给：标题、期刊、一句话结论、链接。
输出不超过 800 字。如果不足 5 篇，有几篇列几篇，不要凑数。

4.6 API Key

什么时候用：想在自己的程序、脚本、其他客户端里调用这套能力。

4.6.1 生成与命名

1. 进 设置 → API Key。
2. 点「新建」，起一个能看出用途的名字（如 guide-demo-key、weekly-report-bot）。
3. 生成后立刻复制——完整 key 只显示一次。

4.6.2 用在哪

典型用法是用 curl 或 SDK 调用对话接口：

curl -X POST "https://lobechat.1661688.xyz/api/v1/chat" \
  -H "Authorization: Bearer sk-lh-你的key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.5-flash-lite",
    "provider": "newapi",
    "messages": [{"role": "user", "content": "只回复两个字：可用"}],
    "stream": false
  }'

正常返回：

{"data":{"content":"可用","model":"gemini-3.5-flash-lite","provider":"newapi"},
 "message":"Chat completed successfully","success":true}

三个可用端点：

要流式，走 POST /api/v1/responses，但它的 model 字段语义是「助手标识」，直接填模型名会报 Agent not found。用之前先确认你的调用方式。

4.6.3 泄露了怎么办

立刻在 设置 → API Key 里删除该 key，然后新建一个。删除是即时生效的，旧 key 下一次请求就会被拒。

三条纪律：

• 不要把 key 写进前端代码或公开仓库。
• 不同用途用不同 key，方便单独吊销。
• 定期看 last_used_at，发现异常时间点就吊销。

4.7 看板

什么时候用：想知道自己用了多少、花在哪、任务跑得怎么样。

4.7.1 指标卡能看什么

看板由一张张卡片组成，常见的有：

• 本周 token 消耗
• 各模型调用次数
• 任务执行成功率
• 存储占用

4.7.2 不能看什么

要说清楚边界：自建版的看板不是计费系统。它给的是使用量参考，不等于账单金额；也不做按用户/按项目的成本分摊。

4.7.3 自定义看板项

点「添加卡片」，选指标类型。实测提醒：看板卡片必须通过对话生成——在对话里让助手「编写一个监控组件」，它才会产出可挂载的卡片。手动新建往往只能建一个空看板。

看板的实际界面。卡片上显示的数值是使用量参考，不是账单金额。

可复制示例

帮我做一个看板组件：显示最近 7 天每天的对话条数，用柱状图，
标题叫「本周对话量」，数据从我的会话记录里取。

本篇小结

• 内置助手开箱即用；自建助手按「角色/任务/约束/禁止」四段写提示词。
• 群聊要先手动拉成员；控场靠点名和给顺序。
• 任务负责「记录与指派」，不负责「自动执行」；自动执行靠定时任务。
• 定时任务最容易烧钱，先低频试跑，限定输出长度。
• API Key 只在创建时显示一次；三个端点各有边界，流式要走 /responses。
• 看板是参考指标，不是账单；卡片要靠对话生成。

下一篇《场景专题》把前面所有能力串成一条能出成品的流水线，重点是科研投稿全流程。