BossAgentsMTClaw 多任务连续执行能力设计方案
基于 MTClaw 打造工业级多步智能体，实现"工业界的 Cursor"
一、背景与定位
1.1 大模型的能力边界
大模型本身不天然具备多步规划、连续执行、任务拆解的能力——它是"文本生成器"而非"任务执行器"。单次前向传播、无状态、无执行，决定了它不能自主决定"下一步做什么"，也无法在生成过程中暂停、调用工具、观察结果再决定下一步。
| 大模型不能做什么 | 原因 |
|---|---|
| 自主多步规划 | 没有"目标导向"的自我意识，只会"接话"，不会主动拆解目标 |
| 工具调用编排 | 生成的是文本而非执行指令，不能自己决定"先查库存、再算成本、最后出报告" |
| 状态追踪 | 没有"执行状态"概念，每次推理相互独立 |
| 失败重试 | 不会主动反思并重新尝试 |
| 结果合成 | 只能拼接子结果，不能归纳核心结论 |
1.2 什么是"工业界的 Cursor"
Cursor = 理解代码上下文 → 拆解编程任务 → 调用工具 → 连续执行 → 完成复杂开发任务
BossAgents = 理解工业上下文 → 拆解业务任务 → 调用数字员工 → 连续执行 → 完成复杂业务任务
关键差异：Cursor 面对的是代码文件，BossAgents 面对的是工业对象（Part、BOM、工艺、设备、质量数据等）。这套多任务连续执行能力，正是"工业界 Cursor"的技术基石。
1.3 从单步到多步的架构演进
【单步模式】用户 → MTClaw 路由 → 1 个数字员工 → 返回结果（一问一答，独立执行）
【多步模式】用户 → 深度思考 → 任务规划 → N 个数字员工协同 → 结果合成 → 返回（复杂目标，协同执行）
【连续模式】用户 → 深度思考 → 执行 → 反思 → 优化 → 执行 → … → 完成（持续迭代，自我优化）
二、整体架构
┌────────────────────────────────────────────────────────────┐
│ 用户交互层 │
│ Web / 小程序 / 飞书 / API — 像发微信一样管工厂 │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ MTClaw 多步智能体调度层 │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 意图理解器：简单任务→直接路由 | 复杂任务→进入规划器 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 任务规划器：目标拆解→依赖分析→执行顺序编排→并行/串行 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 执行调度器：子任务分发→状态追踪→失败重试→结果收集 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 结果合成器：子结果聚合→推理链生成→置信度评估→建议 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ N 个数字员工执行层 │
│ 采购助手 | 成本优化师 | 工艺管家 | BOM管理员 | 质量巡检员 │
│ 库存预警员 | 供应商管家 | 老板助理 | 报告分析师 | ... │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ SCSAI PLM 数据底座 │
│ Part | BOM | ECO | 工艺 | 设备 | 质量 | 供应商 | 订单 │
└────────────────────────────────────────────────────────────┘
三、核心模块设计
3.1 意图理解器（复杂度判断与分流）
核心：判断任务复杂度，分流到单步或多步执行。
L1 规则引擎极速通道——命中即判"简单"：
/^(查|看|多少|有没有|是什么)/ → 简单
/^(帮我查|帮我看看|告诉我)/ → 简单
/^(库存|价格|BOM|供应商|订单)\s*(是|为|多少)/ → 简单
复杂任务关键词通道——命中即判"复杂"：
/优化|改进|提升|降低|减少|增加/ → 复杂
/分析|评估|对比|规划|制定/ → 复杂
/为什么|什么原因|如何处理|怎么办/ → 复杂
/工艺|流程|方案|策略|计划/ → 复杂
/BOM成本|供应链|质量管控|安全合规/ → 复杂
L2 模型深度判断：规则未命中时，端侧模型二次判断，输出 simple 或 complex。
3.2 任务规划器（LLM 拆解 → 工具映射 → 拓扑排序）
核心：将 LLM 输出映射到可用工具，计算执行顺序（拓扑排序，支持并行/串行决策）。
LLM 任务分解 Prompt 要点：
- 每个子任务必须是可独立执行的业务动作
- 子任务之间如有依赖关系需明确标注
- 总步数不超过 8 步
- 最后一步是结果汇总或方案生成
工具映射表（数字员工 → 关键词）示例：
| 工具名 | 关键词 |
|---|---|
| procurement_assistant | 采购、询价、供应商、比价 |
| cost_optimizer | 成本、优化、降本、BOM |
| process_optimization | 工艺、流程、参数、工序 |
| bom_manage | BOM、物料清单、产品结构 |
| quality_inspect | 质量、检验、合格、缺陷 |
| stock_alert | 库存、仓储、物料、备货 |
| vendor_review | 供应商、评审、资质、绩效 |
| report_generator | 报告、汇总、报表、分析 |
| compliance_check | 合规、审批、变更、ECR |
| boss_assistant | 决策、经营、管理、报表 |
执行状态结构（智能体独立维护）：
{
"planId": "plan_20260802_001",
"userGoal": "优化生产工艺降低成本5%",
"currentStep": 3,
"completedSteps": [
{ "step": 1, "status": "completed", "result": {} },
{ "step": 2, "status": "completed", "result": {} }
],
"pendingSteps": [
{ "step": 3, "status": "pending" },
{ "step": 4, "status": "pending" }
]
}
3.3 执行编排器（依赖调度 + 重试 + 状态追踪）
核心：按依赖关系调度，支持并行执行，失败自动重试（最多 3 次，指数退避）。
- 依赖检查：执行某步骤前确认其前置步骤已完成
- 失败重试：
retryCount < 3时换策略重试，否则升级给用户 - 状态持久化：工业级系统不能只靠内存，需支持任务恢复与进度查询
3.4 结果合成器（子结果聚合 + 推理链 + 置信度 + 建议）
核心：聚合各子任务结果，生成最终回答。
合成 Prompt 结构：用户目标 + 任务规划（推理过程/总步数/成功失败数）+ 成功子任务结果 + 失败任务说明 → 输出 JSON（summary / keyFindings / reasoningChain / confidence / suggestions）。
数据亮点提取：从子结果中提取 count / total / amount / rate / percent / score / status 等关键字段，结构化呈现。
3.5 连续任务管理器（上下文 + 历史 + 累积数据）
核心：支持"继续、然后、下一步、接着、还有"等延续指令，跨轮次保持执行上下文。
- 会话上下文：
history[]+activePlan+lastResult+accumulatedData - 延续判断：命中延续关键词或存在未完成步骤 → 继续执行剩余步骤
- 数据累积：每轮结果并入
accumulatedData，供后续轮次引用
四、与数字员工集成
所有数字员工按统一格式注册为工具，供规划器匹配与执行器调用：
{
"name": "procurement_assistant",
"description": "执行采购流程：查询供应商、询价比价、生成采购订单",
"staffId": "DS-PROC-001",
"keywords": ["采购", "询价", "供应商", "比价", "下单"],
"domain": "采购管理",
"capabilities": ["供应商查询", "价格比对", "订单生成"],
"parameters": [
{ "name": "material", "type": "string", "required": true, "description": "采购物料名称" },
{ "name": "quantity", "type": "number", "required": true, "description": "采购数量" }
]
}
执行器通过 POST /api/digital-staff/run 调用数字员工：
{
"staffId": "DS-COST-001",
"intent": "分析当前BOM成本构成",
"userId": "demo_user",
"parameters": {}
}
五、配置示例
# MTClaw 多步规划配置
deep_think:
enabled: true
max_steps: 8
parallel_execution: true
fallback_to_single: true
# 连续任务配置
continuous_mode:
enabled: true
context_ttl: 3600
max_history: 20
# 工具注册
tools_registry:
auto_discover: true
refresh_interval: 300
# 深度思考容错
deep_think:
default_retries: 3
timeout: 60000
max_steps: 8
六、使用示例
用户输入："帮我优化磷酸一铵的生产工艺，在保证质量的前提下降低成本5%以上，并给出具体的实施建议"
任务规划（5 步，串行依赖）：
- 分析当前 BOM 成本构成 → cost_optimizer
- 识别主要成本驱动因素 → cost_optimizer
- 制定工艺优化方案 → process_optimization
- 评估可行性和风险 → compliance_check
- 生成最终建议报告 → report_generator
预期输出：
模式: multi_step_deep_think
推理: 需先分析成本构成，识别驱动因素，再制定方案并评估可行性
总步骤: 5 | 完成: 5 | 失败: 0 | 总耗时: 12456ms
最终结论:
通过优化原材料采购（替换为材料B）、调整关键工艺参数（温度降低5%）和部分自动化改造，
可实现综合成本降低6.2%，超出5%目标。建议分三阶段实施，预计3个月收回投资。
关键发现:
• 原材料A占比42%，是最大成本驱动因素，替代材料B可降本8%
• 温度参数优化后能耗可降低3%
• 整体方案可行性高，主要风险在于需重新小试验证
置信度: 82%
建议下一步:
• 安排小试验证批次
• 与供应商洽谈材料B长期供应价格
• 制定详细3阶段实施计划
七、能力对比
| 能力维度 | 单步 MTClaw | 增强版（多步） | 工业界 Cursor 目标 |
|---|---|---|---|
| 单任务响应 | ✅ | ✅ | ✅ |
| 任务拆解 | ❌ | ✅ | ✅ |
| 多步骤执行 | ❌ | ✅ | ✅ |
| 并行执行 | ❌ | ✅ | ✅ |
| 失败重试 | ❌ | ✅ | ✅ |
| 上下文关联 | ❌ | ✅ | ✅ |
| 结果合成 | ❌ | ✅ | ✅ |
| 连续对话 | ❌ | ✅ | ✅ |
八、技术验证点
| 验证项 | 方法 | 预期结果 |
|---|---|---|
| 任务规划准确性 | 50 个真实业务场景测试 | 规划准确率 ≥ 85% |
| 执行成功率 | 多步任务端到端执行 | 完整执行率 ≥ 80% |
| 失败恢复能力 | 模拟工具异常 | 自动重试成功率 ≥ 70% |
| 连续任务能力 | 多轮对话场景 | 上下文保持率 ≥ 90% |
九、结论
大模型做的是"回答问题"，智能体做的是"执行任务"。多任务连续执行能力全部由智能体架构独立实现：规划器弥补"不能拆解"，编排器弥补"不能执行/重试"，合成器弥补"不能归纳"，上下文管理器弥补"不能连续"。这套方案完全基于现有 MTClaw 和数字员工基础设施，无需大规模重构，是"工业界 Cursor"的技术基石。
