2.3 任务分解与协作流程：把大戏拆成幕

2.3 任务分解与协作流程：把大戏拆成幕

本节摘要：任务分解器（Task Specifier）是 CAMEL 编排链上最被低估的部件：它把一句任务卡细化成结构化的执行文本，为甲方的逐轮指令供弹药。本节讲清细化的正确姿势、协作流程里细化解与对话解的两种跑法，以及幕拆多粗多细的工程判据。上一节写好了剧本，本节把整场戏排出幕次表。

从一句九个字的任务卡说起

"开发一个股票交易机器人"——这句话在 1.2 节的道具清点里合格，因为那是任务卡该有的样子：短、面向结果。但甲方演员拿着这句话每轮下指令时，它太粗了：第一轮该从哪下手？验收线画在哪？如果没有上游帮它把任务卡"磨尖"，甲方演员的指令质量全凭模型临场发挥，方差极大。

任务分解器就是那个磨刀的工位。它本身是一个配备专属提示的智能体，输入原始任务卡与两个角色名，输出一段细化后的任务描述——通常几百字，包含目标拆解、约束条件、预期产出。关键在理解它的定位：分解器不拆给人类看，拆给甲方演员看。它不是生成项目计划书的工具，是给第一个角色的剧本补充弹药。

图里两个分支值得各说一句。不开细化解不是错误选项：任务本身很小时（"写一个快排函数"），细化反而画蛇添足，白白多一次调用。开了细化解也不是万能：细化文本的质量依赖分解器提示，泛泛的细化等于没拆。

细化文本长什么样

看一次真实的细化输出（同一句任务卡，节选）：

【细化后的任务】
开发一个股票市场交易机器人的 Python 脚本，具体包括：
1. 行情获取模块：按股票代码与区间拉取逐日行情，含异常重试；
2. 信号模块：实现双均线交叉策略，输出买卖信号；
3. 回测模块：对历史区间回测，输出累计收益与最大回撤；
4. 主流程：将三个模块串成可运行脚本，附使用说明。
约束：仅用公开数据接口；代码分文件组织；每步可独立验证。
预期产出：可运行的脚本与简要说明文档。
​

对照原始任务卡，细化文本干了三件事：把"一个机器人"落成四个有边界的模块；给每个模块挂了隐含的验收口径（"含异常重试""输出两个数值"）；声明了全局约束（公开接口、可独立验证）。甲方演员拿到它，2.2 节模板里"指令必须可追溯总目标"的规则就有了着落——追溯的对象从一句空话变成了四条具体的幕次。

框架里开启细化解只需要一个开关：

from camel.agents import RolePlaying
from camel.typing import ModelType

session = RolePlaying(
    assistant_role_name="Python 程序员",
    user_role_name="股票交易员",
    task_prompt="开发一个股票市场交易机器人的 Python 脚本",
    with_task_specify=True,        # 开关：True 时先跑一次任务细化
    task_specify_agent_kwargs=dict(model_type=ModelType.GPT_4),  # 分解器用强模型
    model_type=ModelType.GPT_4,
)
print(session.specified_task_prompt[:200])   # 查看细化文本前 200 字
​

开发一个股票市场交易机器人的 Python 脚本，具体包括：1. 行情获取模块：
按股票代码与区间拉取逐日行情，含异常重试；2. 信号模块：实现双均线交叉……
​

一个容易被忽略的预算细节：with_task_specify=True 意味着每次会话多一次模型调用。跑批量实验时（比如第 4 章生成一百场戏的数据集），这一笔乘以一百就是实打实的成本。批量场景下更经济的跑法是细化一次、复用多次——把细化文本缓存下来，后续会话直接以它作为任务卡开场。

幕拆多粗：三条工程判据

细化解解决"有没有弹药"，拆幕粒度解决"弹药好不好用"。判据有三条，全部围绕验收展开。

判据一：一幕一验收。 每幕必须能对应一条甲方演员可执行的检验动作——跑一个函数、查一段输出、对一组数值。两个模块挤在一幕里，验收就变成了"感觉还行"，坏方案会流进下一幕。

判据二：一幕两到三轮。 幕内对话通常两三轮收敛：第一轮交付、第二轮修正、第三轮验收通过进下一幕。一幕要演七八轮，多半是幕太大或验收线不清；一幕一轮就过，幕又太碎，指挥成本超过了任务本身。

判据三：依赖方向单向。 幕与幕之间按依赖排列，后面的幕只消费前面幕的产出，不开回头路。需要返工时，重开一幕"修 X"，而不是让对话倒回第三轮——历史回滚在消息累积的架构里代价极高。

三条判据套到交易机器人上：行情、信号、回测、主流程各成一幕，共四幕；按每幕两到三轮估算，十到十四轮预算正好。这也回答了 1.2 节留下的伏笔——轮次上限为什么跟着任务形态走：上限 = 幕数 × 幕均轮数 + 余量，余量给两轮，防返工。

协作流程全串一遍

把本章三个部件串成完整的时间线：分解器先跑，产出细化文本；细化文本进两侧系统消息；甲方演员按幕次表下达第一条指令；对话循环开演，逐轮累积；每幕收敛时甲方核对验收线，通过则进下一幕；四幕全过，甲方单独一行输出谢幕口令；框架检测口令，停演，产出完整对话数据。人类在这条时间线上出现两次：开演前递任务卡，谢幕后收数据——中间全程无人值守，这正是这套机制区别于人工提示迭代的根本价值。

一个收尾提醒：分解器产出的细化文本不是圣经。它是甲方演员的弹药，不是人类的验收清单——最终判定任务完成的是甲方在对话里的验收行为。把细化文本当自动生成的项目计划书去管理，就把它用重了；把它当磨尖了的任务卡，就刚好。

幕次表排好了，后台还剩最后一站：这一堆部件在框架里各住哪间房，谁调用谁。下一节摊开剧团架构图。