在进行拆解评估时，我们将任务特征映射到四层架构选择，类似于传统NLP中根据任务类型选择算法模型的逻辑，LLM inside智能应用的引擎选择的原则，基于低门槛、成本效率、质量高、易治理、可灵活扩展和迁移的标准。

核心框架：TASK-EVAL模型

选择架构前，需要对任务进行六个维度的评估：

第一层：Completion as Feature

适用条件（满足以下全部）

典型任务模式

模式1：内容转换（Transform），比如信息搜索、客服、文档改写纠错扩展等

• 输入：结构化数据 → 输出：自然语言描述
• 例：天气数据转播报文本、股票数据转简报

模式2：内容提取（Extract），图片、文本、音频、视频等多模态、复杂来源、异构的数据，需要结构化的计算管线和模型中的

• 输入：非结构化文本 → 输出：结构化字段
• 例：从邮件提取会议时间地点、从简历提取技能标签

模式3：内容扩展（Expand），比如写文章、产品介绍、海报宣传、编码等

• 输入：简短提示 → 输出：扩展文本
• 例：邮件续写、代码注释生成、产品描述扩写

模式4：内容压缩（Compress），比如简报、打标签、分类和提取构建知识图谱

• 输入：长文本 → 输出：摘要或关键词
• 例：文章摘要、对话总结、文档标签

第二层：Workflow Orchestration

适用条件（满足以下任一组合）

组合A：复杂确定性流程

• Task Complexity: 中-高（3-10个步骤，有分支逻辑）
• Ambiguity: 低（每个步骤的输入输出可明确定义）
• State Volatility: 中（步骤间需要传递状态）

组合B：人机协作刚需

• Error Cost: 高（关键步骤需人工确认）
• Auditability Need: 高（必须记录完整处理轨迹）

组合C：多系统集成

• Knowledge Scope: 广（需要查询多个异构数据源）
• Velocity Requirement: 可接受异步（分钟级延迟）

从第一层迁移到第二层的信号

• Prompt复杂度持续增加（> 2k tokens），包含大量条件分支说明
• 单次调用成功率下降，需要后处理修正
• 需要引入外部API查询（实时数据、计算服务）
• 业务逻辑要求"先A后B"的强制顺序

第三层：Agent with Tool Use

适用条件（满足以下核心组合）

核心组合：开放性问题 + 工具可解决

• Task Complexity: 高（步骤不可预先枚举）
• Ambiguity: 中-高（需要探索澄清）
• State Volatility: 高（环境动态变化）
  
  

从第二层迁移到第三层的信号

• Workflow的分支逻辑爆炸，维护成本超过收益
• 需要处理大量边缘情况，显式规则难以覆盖
• 任务具有探索性，最优路径因输入而异
• 工具调用序列需要根据中间结果动态调整

不适用第三层的信号（保持Workflow）

• 步骤顺序有严格的业务规则（如合规要求）
• 失败成本极高，必须可预测（如金融交易执行）
• 工具集无法覆盖问题空间，Agent会陷入无限探索

第四层：Multi-Agent Coordination

适用条件（满足以下任一高阶需求）

需求A：领域知识隔离

• Knowledge Scope: 极广（跨多个专业领域）
• 单一Agent的上下文无法同时容纳多领域深度知识
• 领域间需要防火墙（安全/隐私/权限）

需求B：并行探索与验证

• Task Complexity: 极高（需要多路径并行探索）
• 单一串行路径效率过低
• 需要多视角验证（如模拟红蓝对抗）

需求C：复杂组织协调

• 任务本身涉及多方利益相关者
• 需要模拟协商、谈判、共识构建过程
  
  

从第三层迁移到第四层的信号

• 单Agent的上下文窗口成为瓶颈（无法加载全局状态）
• 需要同时探索多个独立路径（如A/B方案并行）
• 领域知识冲突（如法律合规 vs 技术创新）
• 观察到单Agent在不同子任务间"认知切换"成本过高

不适用第四层的信号（保持单Agent）

• Agent间的通信开销超过并行收益
• 任务本身串行依赖强，无法解耦
• 团队缺乏分布式系统调试经验

成本-效果权衡矩阵

选择原则：在满足业务需求的前提下，选择复杂度最低的架构。只有当低层架构遇到不可逾越的瓶颈时，才向高层迁移。

演进路径与回退策略

向上迁移的触发条件：

1. 业务需求变化（复杂度增加）
2. 技术能力成熟（团队掌握更高层架构）
3. 成本结构变化（LLM成本下降使高层架构经济可行）

回退策略（高层架构失败时）：

• 第三层 → 第二层：将常见成功路径固化为workflow，Agent处理例外
• 第四层 → 第三层：合并Agents为单Agent的多工具集，减少协调开销
• 通用：保留人工介入通道，设置优雅降级路径

目的要归一到价值和效用

这个方法论的核心是"克制"——不为技术先进性选择架构，而为问题特征选择最适工具。从Completion到Multi-Agent，每一层都引入了新的复杂度、不确定性和成本。只有当低层架构确实无法满足需求时，才值得承担这些代价。

最终检验标准不是架构的复杂度，而是用户价值、企业价值的交付。

目前还有进一步迭代优化空间：

• 这是一个“半工程化、半专家裁量”的混合体系，半形式化决策体系。

• 不同架构师可能做出不同选择，

• 迁移信号目前偏“症候学”，不是“触发器”