BossAgentsMTClaw Multi-Task Continuous Execution Capability Design Solution
Building an Industrial-Grade Multi-Step Agent Based on MTClaw to Realize the "Cursor for Industry"
I. Background and Positioning
1.1 The Capability Boundaries of Large Language Models
Large language models do not inherently possess capabilities for multi-step planning, continuous execution, or task decomposition—they are "text generators" rather than "task executors." Single forward passes, statelessness, and lack of execution mean they cannot autonomously decide "what to do next," nor can they pause during generation, call tools, observe results, and then decide the next step.
| What Large Models Cannot Do | Reason |
|---|---|
| Autonomous Multi-Step Planning | No goal-oriented self-awareness; they only "continue the conversation," unable to actively decompose goals |
| Tool Call Orchestration | They generate text, not execution commands, and cannot decide on sequences like "check inventory first, then calculate cost, finally generate report" |
| State Tracking | No concept of "execution state"; each inference is independent |
| Failure Retry | Cannot actively reflect and retry |
| Result Synthesis | Can only concatenate sub-results, not summarize core conclusions |
1.2 What is the "Cursor for Industry"
Cursor = 理解代码上下文 → 拆解编程任务 → 调用工具 → 连续执行 → 完成复杂开发任务
BossAgents = 理解工业上下文 → 拆解业务任务 → 调用数字员工 → 连续执行 → 完成复杂业务任务
关键差异：Cursor 面对的是代码文件，BossAgents 面对的是工业对象（Part、BOM、工艺、设备、质量数据等）。这套多任务连续执行能力，正是"工业界 Cursor"的技术基石。
1.3 Architectural Evolution from Single-Step to Multi-Step
【单步模式】用户 → MTClaw 路由 → 1 个数字员工 → 返回结果（一问一答，独立执行）
【多步模式】用户 → 深度思考 → 任务规划 → N 个数字员工协同 → 结果合成 → 返回（复杂目标，协同执行）
【连续模式】用户 → 深度思考 → 执行 → 反思 → Optimize → 执行 → … → 完成（持续迭代，自我优化）
二、整体架构
┌────────────────────────────────────────────────────────────┐
│ 用户交互层 │
│ Web / 小程序 / 飞书 / API — 像发微信一样管工厂 │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ MTClaw 多步智能体调度层 │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 意图理解器：简单任务→直接路由 | 复杂任务→进入规划器 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 任务规划器：目标拆解→依赖分析→执行顺序编排→并行/串行 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 执行调度器：子任务分发→状态追踪→失败重试→结果收集 │ │
│ ├──────────────────────────────────────────────────────┤ │
│ │ 结果合成器：子结果聚合→推理链生成→置信度评估→建议 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ N 个数字员工执行层 │
│ 采购助手 | 成本优化师 | 工艺管家 | BOM管理员 | 质量巡检员 │
│ 库存预警员 | 供应商管家 | 老板助理 | 报告分析师 | ... │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ SCSAI PLM Data Foundation │
│ Part | BOM | ECO | 工艺 | 设备 | 质量 | 供应商 | 订单 │
└────────────────────────────────────────────────────────────┘
三、核心模块设计
3.1 意图理解器（复杂度判断与分流）
核心：判断任务复杂度，分流到单步或多步执行。
L1 Rule Engine Express Lane—Immediate Judgment on "Simple" Hits:
/^(查|看|多少|有没有|是什么)/ → 简单
/^(帮我查|帮我看看|告诉我)/ → 简单
/^(库存|价格|BOM|供应商|订单)\s*(是|为|多少)/ → 简单
复杂任务关键词通道——命中即判"复杂"：
/Optimize|改进|提升|降低|减少|增加/ → 复杂
/分析|评估|对比|规划|制定/ → 复杂
/为什么|什么原因|如何处理|怎么办/ → 复杂
/工艺|流程|方案|策略|计划/ → 复杂
/BOM成本|供应链|质量管控|安全合规/ → 复杂
L2 模型深度判断：规则未命中时，端侧模型二次判断，输出 simple 或 complex。
3.2 Task Planner (LLM Decomposition → Tool Mapping → Topological Sorting)
Core: Map LLM output to available tools, compute execution order (topological sorting, supporting parallel/serial decisions).
Key Points for LLM Task Decomposition Prompt:
- Each subtask must be an independently executable business action
- Dependencies between subtasks must be clearly marked.
- Total steps should not exceed 8.
- The final step is result summarization or solution generation.
Tool Mapping Table (Digital Employee → Keywords) Example:
| Tool Name | Keywords |
|---|---|
| procurement_assistant | procurement, inquiry, supplier, price comparison |
| cost_optimizer | cost, optimization, cost reduction, BOM |
| process_optimization | process, workflow, parameters, operation |
| bom_manage | BOM, bill of materials, product structure |
| quality_inspect | quality, inspection, qualification, defect |
| stock_alert | inventory, warehousing, material, stock-up |
| vendor_review | supplier, review, qualification, performance |
| report_generator | report, summary, statement, analysis |
| compliance_check | compliance, approval, change, ECR |
| boss_assistant | decision, operation, management, report |
Execution Status Structure (Maintained independently by the agent):
{
"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 次，指数退避）。
- Dependency Check: Confirm that prerequisite steps are completed before executing a step.
- Failure Retry: Retry with a different strategy when retryCount is reached, otherwise escalate to the user.
- State Persistence: Industrial-grade systems cannot rely solely on memory; they must support task recovery and progress query.
3.4 Result Synthesizer (Sub-result Aggregation + Reasoning Chain + Confidence + Suggestions)
Core: Aggregate results from all subtasks to generate the final answer.
Synthesize Prompt Structure: User Goal + Task Planning (Reasoning Process/Total Steps/Success & Failure Counts) + Successful Sub-task Results + Failed Task Explanation → Output JSON (summary / keyFindings / reasoningChain / confidence / suggestions).
Data Highlight Extraction: Extract key fields such as count / total / amount / rate / percent / score / status from sub-results and present them in a structured format.
3.5 Continuous Task Manager (Context + History + Accumulated Data)
Core: Supports continuation instructions like "continue, then, next, after that, and also" to maintain execution context across rounds.
- Session Context: history[] + activePlan + lastResult + accumulatedData
- Continuation Judgment: If continuation keywords are triggered or there are unfinished steps → continue executing remaining steps.
- Data Accumulation: Merge each round's results into accumulatedData for reference in subsequent rounds.
IV. Integration with Digital Employees
All digital employees are registered as tools in a unified format for planner matching and executor invocation:
{
"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%以上，并给出具体的实施建议"
Task Planning (5 steps, serial dependency):
- Analyze current BOM cost structure → cost_optimizer
- Identify main cost drivers → cost_optimizer
- Develop process optimization plan → process_optimization
- Assess feasibility and risks → compliance_check
- Generate final recommendation report → report_generator
Expected output:
模式: multi_step_deep_think
推理: 需先分析成本构成，识别驱动因素，再制定方案并评估可行性
总步骤: 5 | 完成: 5 | 失败: 0 | 总耗时: 12456ms
最终结论:
通过优化原材料采购（替换为材料B）、调整关键工艺参数（温度降低5%）和部分自动化改造，
可实现综合成本降低6.2%，超出5%目标。建议分三阶段实施，预计3个月收回投资。
关键发现:
• 原材料A占比42%，是最大成本驱动因素，替代材料B可降本8%
• 温度参数优化后能耗可降低3%
• 整体方案可行性高，主要风险在于需重新小试验证
置信度: 82%
建议下一步:
• 安排小试验证批次
• 与供应商洽谈材料B长期供应价格
• 制定详细3阶段实施计划
七、能力对比
| 能力维度 | 单步 MTClaw | 增强版（多步） | 工业界 Cursor 目标 |
|---|---|---|---|
| Single-task response | ✅ | ✅ | ✅ |
| Task decomposition | ❌ | ✅ | ✅ |
| Multi-step execution | ❌ | ✅ | ✅ |
| Parallel execution | ❌ | ✅ | ✅ |
| Failure retry | ❌ | ✅ | ✅ |
| Context association | ❌ | ✅ | ✅ |
| Result synthesis | ❌ | ✅ | ✅ |
| Continuous dialogue | ❌ | ✅ | ✅ |
8. Technical Validation Points
| Validation Item | Method | Expected Result |
|---|---|---|
| Task planning accuracy | 50 real business scenario tests | Planning accuracy ≥ 85% |
| Execution success rate | End-to-end multi-step task execution | Full execution rate ≥ 80% |
| Failure recovery capability | Simulate tool exceptions | Automatic retry success rate ≥ 70% |
| Continuous task capability | Multi-turn dialogue scenarios | Context retention rate ≥ 90% |
9. Conclusion
Large models are for "answering questions"; agents are for "executing tasks." All multi-task continuous execution capabilities are independently implemented by the agent architecture: the planner compensates for "inability to decompose," the orchestrator compensates for "inability to execute/retry," the synthesizer compensates for "inability to summarize," and the context manager compensates for "inability to continue." This solution is fully based on existing MTClaw and digital employee infrastructure, requiring no large-scale refactoring, and serves as the technical foundation for an "industrial Cursor."
