1. 为什么你的 Agent 总在“用力过猛”或“敷衍了事”如果你正在做 Agent 产品大概率遇到过这两种尴尬用户只是问“1024 乘 768 等于多少”Agent 却一本正经地启动了多阶段规划先拆解任务、再调用搜索、最后生成一份带小标题的报告反过来用户说“帮我规划下季度营销活动”Agent 却直接甩出一段泛泛而谈的文案连目标人群和预算都没问。前者是简单任务复杂化后者是复杂任务简单化。这两种失败模式的根因是同一个Agent 缺少一套可落地的复杂度判断机制。复杂度判断不是给任务贴“简单/困难”标签而是决定执行策略的开关。它要回答三个问题这个任务需要几步、需不需要外部工具、有没有歧义或高风险。判断准了简单任务走 Micro 层直接执行中等任务走 Meso 层分阶段规划模糊任务走 Macro 层先澄清再动手。判断错了要么浪费 token 和延迟要么交付一堆不可用的结果。这篇内容面向正在自建 Agent 流程的开发者尤其是用大模型做任务编排、工具调用、多步规划的场景。我会以 Manus 这类 Agent 的公开设计思路为参照拆出一套可复制的复杂度判断配置骨架并给出在 TaoToken 上接入模型、跑通验证的完整步骤。你不需要从零发明评分模型照着改参数就能用。2. 复杂度判断的骨架七维加权 三条启发式规则Manus 的思路是“定量打分 定性短路”两层。第一层是七维度加权评分每个维度按 0–3 打分再乘权重加总后映射到执行层次。第二层是三条启发式规则优先级高于评分命中就直接决策不再走完整计算。七维度的权重分配如下你可以直接拿去当初始配置维度权重核心考量打分建议不确定性与模糊度3.0指令是否清晰、有无歧义0 明确 / 1 轻微模糊 / 3 高度模糊步骤数量与依赖性2.0步骤数及依赖关系0 单步 / 1 线性 2–3 步 / 3 多步依赖领域专业性与风险1.8是否涉及法律、金融、医疗0 通用 / 2 专业 / 3 高风险工具需求与组合1.5调用工具数量与协同0 无工具 / 1 单工具 / 3 多工具链信息获取与来源1.5是否需外部信息及来源数0 封闭 / 1 单源 / 3 多源整合数据处理与分析1.2结构化/非结构化处理0 无 / 1 简单提取 / 3 建模分析创造性与生成需求1.0是否需生成新内容0 无 / 1 改写 / 3 原创设计加权总分映射到三个执行层次0–10 分走 Micro直接执行11–30 分走 Meso创建结构化计划分阶段执行31 分以上走 Meso 高级或 Macro多阶段计划或先澄清需求。三条启发式规则负责处理极端情况。规则一“模糊性优先”如果指令里出现“分析一下市场”这类缺少对象和目的的表述直接判定为模糊任务跳过评分进入 Macro 对话澄清。规则二“高风险优先”命中“合同”“诊断”“投资建议”等词自动把复杂度提升一级并附加风险提示。规则三“简单任务捷径”目标单一、工具固定比如纯计算或格式转换直接走 Micro绕过规划。这套骨架的价值在于它把“判断复杂度”从模糊直觉变成了可调参的工程模块。你可以先照搬权重再根据自己业务的失败案例微调。3. 在 TaoToken 上接入判断模块可复制配置要把这套判断逻辑跑起来你需要一个能稳定调用大模型的入口。TaoToken 提供 OpenAI 兼容的 API模型对话、Coding Plan、API Keys 管理都在同一个控制台里。下面是从拿 Key 到写出判断函数的最小路径。第一步在 TaoToken 控制台创建 API Key。访问 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 生成密钥复制保存。注意 Key 只在创建时完整显示一次。第二步配置环境变量。不要硬编码在代码里export TAOTOKEN_API_KEYsk-你的密钥 export TAOTOKEN_BASE_URLhttps://taotoken.net/api第三步写一个复杂度判断函数。核心思路是让模型按七维度输出 JSON 打分你在本地做加权和映射。这样模型只负责“打分”策略映射由你的代码控制方便调试和替换。import os, json from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL] ) WEIGHTS { ambiguity: 3.0, steps: 2.0, domain_risk: 1.8, tools: 1.5, info_source: 1.5, data_process: 1.2, creativity: 1.0 } SYSTEM_PROMPT 你是任务复杂度评估器。对用户指令按七个维度打分每项0-3的整数。 只输出JSON不要解释。字段ambiguity, steps, domain_risk, tools, info_source, data_process, creativity。 打分标准0无/明确1轻微2中等3高。 def score_task(user_input: str) - dict: resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ], temperature0 ) raw resp.choices[0].message.content.strip() scores json.loads(raw) total sum(scores[k] * WEIGHTS[k] for k in WEIGHTS) return {scores: scores, total: round(total, 2)}第四步加启发式规则和策略映射。规则放在打分之前命中就短路HIGH_RISK_WORDS [合同, 诊断, 投资建议, 法律意见] SIMPLE_PATTERNS [计算, 转换, 格式化, 翻译这句话] def decide_strategy(user_input: str) - dict: if any(w in user_input for w in HIGH_RISK_WORDS): return {strategy: Meso-HighRisk, reason: 命中高风险规则} if any(p in user_input for p in SIMPLE_PATTERNS) and len(user_input) 30: return {strategy: Micro, reason: 命中简单任务捷径} if 分析一下 in user_input and len(user_input) 15: return {strategy: Macro, reason: 命中模糊性优先} result score_task(user_input) total result[total] if total 10: strategy Micro elif total 30: strategy Meso else: strategy Meso-Advanced return {strategy: strategy, total: total, scores: result[scores]}这套配置的关键点是模型只做打分策略映射和规则短路都在你的代码里。这样你换模型、调权重、加规则都不影响主流程。如果你要做长期编码类 Agent可以把判断模块和 Coding Plan 结合让复杂编码任务自动进入多阶段计划。4. 验证请求跑三个案例看输出配置写完后用三个典型输入验证判断是否符合预期。我实测下来重点看总分区间和策略是否匹配。案例一简单计算print(decide_strategy(计算 1024 × 768))预期输出命中简单任务捷径strategy 为 Micro不走评分。如果你去掉捷径规则评分总分应该在 0–5 分左右仍然映射到 Micro。案例二中等任务print(decide_strategy(搜索关于大语言模型最新进展的5篇论文并总结它们的核心贡献))预期输出总分落在 20–30 区间strategy 为 Meso。打分大致是 steps3、tools3、info_source3、data_process2、ambiguity1、domain_risk2、creativity2加权后约 26 分。这个分数说明需要分阶段计划但不至于要澄清需求。案例三模糊任务print(decide_strategy(帮我分析一下市场))预期输出命中模糊性优先strategy 为 Macroreason 为“命中模糊性优先”。如果你不设这条规则模型可能给 ambiguity3加权后总分偏高但策略仍然是 Meso-Advanced不会主动澄清。这就是启发式规则的价值它把“该问还是该做”的判断从评分里独立出来。验证时建议把每次的 scores 和 total 打印出来观察不同输入下哪个维度拉高了总分。如果发现“步骤数量”权重过高导致很多任务都进 Meso可以把它从 2.0 调到 1.5 再试。5. 本篇常见错排查第一个坑模型打分不稳定。同一句话两次调用可能给出不同分数。解决办法是把 temperature 设为 0并在 system prompt 里明确“只输出 JSON不要解释”。如果还是飘可以在 prompt 里给每个维度附上 0/1/2/3 的具体例子。第二个坑启发式规则误伤。比如“翻译这句话帮我分析一下市场”会命中模糊性规则但它其实是个明确的翻译任务。解决办法是规则匹配加长度和上下文约束或者把规则命中结果作为“建议”而非“最终决策”让评分结果参与投票。第三个坑总分区间边界模糊。26 分和 31 分可能只差一个维度的打分但策略从 Meso 跳到 Meso-Advanced。建议在边界附近加一个“二次确认”步骤如果总分在 28–33 之间让模型再判断一次“这个任务是否需要多阶段计划”用两次结果投票。第四个坑API 调用报错。常见的是 401 密钥无效或 429 限流。先检查环境变量是否生效再确认 Key 有没有过期。如果频繁 429可以在 TaoToken 控制台看用量或者把判断函数改成批量处理减少调用次数。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 有完整的错误码说明。第五个坑把判断模块和生产库直连。复杂度判断只需要读用户输入不要让它直接操作数据库或执行写操作。判断归判断执行归执行中间加一层策略路由。6. 把判断模块接进你的 Agent 流程复杂度判断不是一次性的分类器而是 Agent 执行前的路由层。你可以把它放在 Agent 主循环的入口收到用户输入后先调 decide_strategy根据返回的 strategy 决定走哪条执行路径。Micro 直接调工具Meso 生成计划再逐步执行Macro 先反问澄清。如果你想让判断更准可以积累一批真实任务日志人工标注“实际需要的执行层次”然后拿这些数据去校准七维权重。权重不是固定的它应该反映你业务里哪类失败最贵。比如法律类产品就把 domain_risk 调到 2.5客服类产品就把 ambiguity 调到 3.5。验证模型判断效果时可以用模型对话功能快速对比不同 prompt 下的打分差异地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。长期跑编码类 Agent 的话Coding Plan 能把多阶段计划的 token 成本压下来入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个实用技巧在判断函数的返回里加一个 confidence 字段用模型对自身打分的置信度比如让它在 JSON 里多输出一个 0–1 的值。当 confidence 低于 0.6 时强制走 Macro 澄清。这比单纯依赖总分区间更稳因为低置信度往往意味着任务本身有歧义而不是复杂度高。