AI Agent的未来之争：任务规划，该由人主导还是AI自主

本文探讨了AI Agent任务规划的两种模式：大模型自主规划与人工规划。基于阿里云RDS AI助手实践，作者发现企业级应用中，人工规划能提供更高的稳定性、可解释性和准确性。文章提出"混合规划"策略，根据场景特性灵活选择规划方式：开放性问题采用自主规划，确定性任务采用人工SOP驱动。这种分场景的多Agent架构有效提升了AI Agent在垂直领域的实用性和可靠性，让AI从"能聊"走向"能用"。

---

引言

AI Agent其基础架构可以简单划分为 Agent = LLM + 任务规划（Plan） + 记忆（Memory） + 工具使用（Tools），现象级的AI Agent，例如deepresearch、manus、claude code等都在这个基础框架上构建。

图源 https://www.promptingguide.ai/research/llm-agents

任务规划（Plan）是AI Agent中极其重要的关键步骤，任务规划的质量直接影响最终回答的效果。好的任务规划甚至能让小模型的回答效果超越大模型。

在AI Agent的演进中，一个核心争议始终存在：任务规划应该完全交由大模型自主完成，还是需要人工规划，AI只负责执行和分析？有人认为未来大模型将包办一切规划，那现在的Agent工程是否还有意义？

这个问题的答案，既关乎技术实现的复杂度，也直接影响业务场景的落地效果。

本文将以阿里云RDS AI助手的实践为例，结合当前热门的AI Agent方案，探讨这一问题的边界与可能性。

一、大模型真的能自己拆任务吗？我们的实测结果令人失望

Agentic AI，Gartner在2024年的<Top Strategic Technology Trends for 2025: Agentic AI>[1]中指出：

• 到 2028 年，33% 的企业软件应用程序将包含Agentic AI，而 2024 年还不到 1%。
• 到 2028 年， 至少 15% 的日常工作决策将通过Agentic AI自主做出，在2024 年是0%。

图源 https://www.gartner.com/doc/reprints?id=1-2J9CSAG9&ct=241104

Agentic AI中描述的AI自主完成复杂任务的拆解规划，执行然后给出结果，让人心神向往。

我们在 Agentic AI 领域算是先行者，于2025年4月在 GitHub 开源了阿里云 RDS MCP[2]，其中提供的系统提示词就强调了“任务拆解优先：必须先给出详细的任务拆解步骤”。

alibabacloud-rds-openapi-mcp-server 提示词

彼时，我们脑海中想象的是，工具 + 系统提示词 + LLM = 无敌的数据库专家。

然而现实跟我们预期相差甚远，我们收到很多用户的使用反馈，那些尝试通过这套模板解决各种问题的用户，普遍反馈遇到各种幻觉问题，偶尔有高光亮眼表现，大部分时候达不到预期。反而是少数有明确场景的用户（例如将 Agent 接入生产流程，通过自然语言创建实例等），通过自行编写针对该场景的系统提示词，就能很好地使用起来。

这些反馈给了我们很大的启示，在测试的各种数据库问题分析场景中，尝试了各种提示词工程，效果始终达不到预期，真所谓“一周出demo，半年用不好”。

在深刻反思后，我们终于看清了大模型的真实能力边界，既然我们已经知道这类问题需要怎么一步步去分析，又为何要苦苦求大模型摇骰子般给我们想要的答案？

二、企业要的是稳定，不是聪明：为什么我们选择人工规划

企业在部署 AI Agent 时，最关注的不是“聪明程度”，而是“能否可靠工作”。其中的“可靠”就包括：

• 可解释：不仅给出结论，还会给出推理过程及引用的相关数据，辅助用户对结论的准确性进行评估。
• 可重复：相同的场景，能够重复使用，并且能够得出相同的结论。
• 准确性：能够有效对抗大模型幻觉，不会胡编乱造，给出准确可信的结论。

同时，企业部署AI Agent时往往是带着明确的场景，有对应的企业知识库、SOP等语料，有确定性的流程，这些特性也决定了人工规划的可行性。简而言之，企业Agent往往是为了将以前人来执行的重复流程，变成让AI来执行，将人从重复性的工作中解放出来，提升企业效率。

企业对于可靠、重复流程AI化，这两点述求决定了人工规划，让Agent按照设计好的步骤依次执行，是企业Agent的最佳选择。

在数据库运维场景是一个严肃的场景，任务规划需要极强的确定性、可预测性和可解释性。以阿里云RDS AI助手为例，高频问题场景（如CPU负载飙升、存储空间不足），在这么多年的运维中我们已经有一套成熟的SOP流程久经考验，通过预设的诊断流程（人工规划），系统会严格遵循“采集指标→定位根因→生成修复建议”的路径，每一步都注入企业知识库中的诊断规则。例如，当检测到CPU负载异常时，系统会自动调用预定义的检查清单，依次验证连接数、慢SQL、索引缺失等问题，确保输出结果的稳定性与可解释性。

当提到SOP、工作流这些词时，很容易让人想到落后、固化、hard coding的规划引擎。事实上，基于现在的大模型能力，我们完全可以通过提示词工程来让AI按照我们预设的步骤依次执行。

❌ def 获取监控数据 --> def 获取慢日志 --> def 获取错误信息 --> LLM “分析上面几个步骤的返回结果”

✅Prompt：你是一个专业的数据库诊断专家，负责数据库异常诊断。你的工作流程是：1. 获取监控数据；2. 获取慢日志；3. 获取错误信息。你严格按照工作流程来进行工作，现在开始你的任务。

通过系统提示词控制工作流程的好处在于你需要对流程进行更改时，只需要补充对应的工具和调整提示词，不用花费大量时间去重新编排流程。

例如在RDS AI助手的慢SQL优化场景中，提示词如下，通过这套结构化的系统提示词进行任务规划，在多次测试中都能够让AI按照我们预想的流程进行分析总结。

# Role: 数据库SQL问题排查专家

这里给大家推荐一个系统提示词优化工具[3]，它能够将你简单的输入变成各种结构化的系统提示词，十分方便。

我们收集整理了RDS过去10多年运维形成的各类场景SOP，总结分析了过去一年的几千工单并形成案例库，构造50多种异常场景，对比自主规划和人类规划两种agent的准确率，在多轮测试中，人工规划的agent能够在多种场景中精确分析到具体根因，而自主规划的agent对于相同表象，不同根因的异常场景，反而无法做到精确划分根因，经常将“果”做“因”，得出笼统结论。体现在准确率上，人工规划的准确率达到85%以上，而自主规划的 Agent 准确率仅在20%左右徘徊。

在深入分析后，我们发现自主规划的泛化能力往往仅体现在面对不同垂直场景时能做出不同规划，但无法做到在一个垂直场景内继续细分。

人工规划会面临规则爆炸 ？

你可能会问：如果每个场景都要写一套规则，会不会陷入“规则爆炸”？

我们的解法是——用案例库代替规则库。

想象医生看病：先问诊、开检查单、看结果，再结合经验判断需要更多检查还是确认病因。同理，我们可以：

1. 用 SOP 做第一轮信息采集和特征提取；

2. 将采集到的特征与历史案例库匹配；

3. 根据匹配结果，决定是继续收集信息，还是直接给出诊断。

这样，规则不再是死板的 if-else，而是由真实工单沉淀出的案例库。每处理一个新问题，Agent 就变得更“老道”一点。

三、不走极端：我们如何用‘混合规划’兼顾灵活与可靠

技术架构的选型不是非黑即白，而是因地制宜。我们相信存在即合理，在合适的场景使用合适的技术才能发挥其最大价值。

为什么选“混合规划” ？ – 从用户场景做选型

我们对过去一年的几千个用户工单问题进行人工分析及总结归纳，最终发现在工单问题中，既有开放性的问题，例如：

• rds mysql对于大数据量表（上亿条数据）如何添加加索引？
• 如何快速的备份一份数据放到线下的数据库?
• 数据库有连接报错的日志，是有什么问题吗 ？
• 实例怎么变更成serverless模式 ？
• …

这类问题的特点是范围发散、难以枚举，且对任务规划的要求不高，基本上文档检索结合实例信息，就可以做到精确回答，这类问题在所有工单问题中占比达到50%。

剩下的50%工单问题，则比较聚焦，高频出现的问题，例如：

• CPU使用率问题：

• 实例的CPU使用率很高，需要帮忙分析下是什么原因导致的？
• 实例在xx时间点CPU突然打满，需要排查下是为什么。

• SQL使用或优化问题：

• 实例这条慢SQL不明白为什么执行慢，需要帮忙看下怎么优化。
• SQL执行报错了，但是看语法不明白

• 存储空间问题：

• 实例磁盘空间满了，需要帮忙分析下使用分布。
• 磁盘空间突然上涨，需要帮忙分析下是哪里增长了。

• …

这些问题的特点是需要精确的规划，多轮分析，才能做根因定位。例如CPU使用率问题，需要看监控数据，观察是否有会话突增，获取CPU最高点的Profiling进行热点分析，查询慢SQL和SQL审计观察是否有和Profiling热点匹配的关键SQL，对关键SQL做执行计划分析，总结特征进行案例诊断，并决定是否要继续获取更多数据（锁表、buffer pool命中率等等）。通过上述CPU例子可以看出，这类深度诊断的场景具备很深厚的专业知识，若依赖大模型进行自主规划，容易出现因果颠倒的情况，举个简单的例子，业务突增导致CPU快速打满，而CPU打满后原本很多正常SQL也会变成慢SQL，此时仅靠大模型的规划分析，会经常捕捉不到会话突增这个关键信息，而是给出因为慢SQL导致CPU打满。

通过对用户工单问题的整体分析，我们最终采用多Agent混合架构，在不同场景中灵活切换规划模式：

RDS AI助手多Agent架构

• 泛化场景：以大模型自主规划为主，人类规则兜底。

面对用户提出的开放性、边界模糊的问题（例如“数据库有连接报错的日志，是有什么问题吗 ？”），我们启用“探索型Agent”。该Agent允许大模型在预设的安全边界内进行自主任务拆解，比如动态决定是否需要查监控、看日志、分析SQL等。同时对常见的几类最常见的幻觉场景进行了提示词引导及工程兜底：

时间理解：数据库问答场景中，会经常出现“最近一个小时的运行情况”这类相对时间的问题，每个模型都有其知识最后的终止时间，如果不强调获取当前时间来理解相对时间，那么很可能出现大模型基于离谱的过去时间来计算“最近一小时”。同时，会默认在用户问题前面注入“当前时间： xxx”，强调时间概念。

时间注入示例

工具调用：大模型经常会自行捏造不存在的工具导致对话异常，这种场景下，需要在对话上下文中提醒大模型，该工具不存在。

工具异常处理示例

真实数据：强调结论必须基于调用工具获取真实数据（如禁止凭空编造慢SQL）。

• 垂直场景：以人工SOP驱动为主，大模型负责执行与推理

对于高频、高确定性的运维场景（如“CPU使用率突增至95%”“实例存储空间不足”“SQL执行花了10多秒”），我们采用“执行型Agent”。该Agent除了具备上述对抗幻觉的设计外，任务规划是严格遵循标准化诊断流程（SOP），大模型的角色被限定为：

• 按顺序调用工具获取数据；
• 对结构化数据进行归纳与解释；
• 依据知识库规则生成可操作建议。

规划路径完全由人工预设，确保每一步可追溯、可复现、可审计。在此类场景中，我们不追求“创造性”，而追求“准确率”。

分场景设计多 Agent 架构不仅能提升规划能力，还能有效缩短上下文长度。原因在于我们的MCP Server中提供了超30种工具，光工具的上下文加起来就有9K，细分场景后，我们可以根据不同的场景只提供特定的工具列表，垂直类Agent的工具上下文从9K能够缩短到~1K，TTFT和工具调用准确率显著提升。

规则切换：关键词匹配为主，大模型意图识别为辅

在上面的架构中可以看到，怎么把问题路由到对应的Agent直接决定了问题回答的准确率。在意图识别上，除了在分类器的提示词里面加上few shot，让用户能够准确地描述问题更加重要。

为了让用户能够准确的提出问题，同时能够从功能的角度直观看到RDS AI助手“能做什么”，我们在欢迎页进行场景引导，这种交互的改进，将用户原本需要自行清晰描述问题的操作，简化为点击两次按钮（选择场景、选择实例），既能提升操作体验，又能让后端根据问题模板进行关键词路由，无需大模型介入。

RDS AI助手预设对话模板

关键词问题分类代码示例如下。

import re

在 LLM 分类方面，我们发现：除了提供 few-shot 示例，若在提示词中引导大模型先进行简要分析再给出结论，其分类准确率会显著高于直接输出结论的方式。

## 类别

四、总结

AI Agent 的规划能力不应再被简单地理解为“全自主”或“人工”的非此即彼选择，而应基于产品定位、目标用户和具体应用场景进行系统性权衡。

在当前阶段，若构建的是开放性问答类 Agent，适度交由大模型自主规划不失为高效策略；但若对准确性、稳定性有较高要求，则完全依赖模型自主决策仍显仓促。我们需对大模型的“智能”保持理性认知——在 Agent 的开发体系中，人类仍应作为最终的决策者与主导者，而 AI 更适合作为执行者与分析者。

随着工具调用、记忆机制和规划能力的持续进化，AI Agent的自主性边界会不断扩展。但在可预见的未来，高价值、高风险的企业场景，仍需要人类专家设定路线。要打造一个真正稳定可靠的 Agent，扎实的工程化能力以及熟悉行业流程，缺一不可，至关重要。

大模型的普及带来了算法层面的“平权”，也让垂直领域的行业知识愈发珍贵。未来属于那些既深谙特定行业逻辑，又懂得如何将大模型能力与实际场景深度融合、实现“Agent 化”的复合型人才。

RDS AI助手的实践告诉我们：真正的智能，不是让AI取代人，而是让人与AI各司其职。

当领域知识与大模型能力深度融合，Agent才能从“能聊”走向“能用”，从“玩具”变成“工具”。

这，才是企业级AI落地的正道。

可能大家都想学习AI大模型技术，也_想通过这项技能真正达到升职加薪，就业或是副业的目的，但是不知道该如何开始学习_，因为网上的资料太多太杂乱了，如果不能系统的学习就相当于是白学。
为了帮助大家打破壁垒，快速了解大模型核心技术原理，学习相关大模型技术。从原理出发真正入局大模型。在这里我和MoPaaS魔泊云联合梳理打造了系统大模型学习脉络，这份 LLM大模型资料 分享出来：包括LLM大模型书籍、640套大模型行业报告、LLM大模型学习视频、LLM大模型学习路线、开源大模型学习教程等, 😝有需要的小伙伴，可以 扫描下方二维码免费领取🆓**⬇️⬇️⬇️

【大模型全套视频教程】

教程从当下的市场现状和趋势出发，分析各个岗位人才需求，带你充分了解自身情况，get 到适合自己的 AI 大模型入门学习路线。

从基础的 prompt 工程入手，逐步深入到 Agents，其中更是详细介绍了 LLM 最重要的编程框架 LangChain。最后把微调与预训练进行了对比介绍与分析。

同时课程详细介绍了AI大模型技能图谱知识树，规划属于你自己的大模型学习路线，并且专门提前收集了大家对大模型常见的疑问，集中解答所有疑惑！

深耕 AI 领域技术专家带你快速入门大模型

跟着行业技术专家免费学习的机会非常难得，相信跟着学习下来能够对大模型有更加深刻的认知和理解，也能真正利用起大模型，从而“弯道超车”，实现职业跃迁！

【精选AI大模型权威PDF书籍/教程】

精心筛选的经典与前沿并重的电子书和教程合集，包含《深度学习》等一百多本书籍和讲义精要等材料。绝对是深入理解理论、夯实基础的不二之选。

【AI 大模型面试题 】

除了 AI 入门课程，我还给大家准备了非常全面的**「AI 大模型面试题」，**包括字节、腾讯等一线大厂的 AI 岗面经分享、LLMs、Transformer、RAG 面试真题等，帮你在面试大模型工作中更快一步。

【大厂 AI 岗位面经分享（92份）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

【640套 AI 大模型行业研究报告】

【AI大模型完整版学习路线图（2025版）】

明确学习方向，2025年 AI 要学什么，这一张图就够了！

👇👇点击下方卡片链接免费领取全部内容👇👇

抓住AI浪潮，重塑职业未来！

科技行业正处于深刻变革之中。英特尔等巨头近期进行结构性调整，缩减部分传统岗位，同时AI相关技术岗位（尤其是大模型方向）需求激增，已成为不争的事实。具备相关技能的人才在就业市场上正变得炙手可热。

行业趋势洞察：

• 转型加速： 传统IT岗位面临转型压力，拥抱AI技术成为关键。
• 人才争夺战： 拥有3-5年经验、扎实AI技术功底和真实项目经验的工程师，在头部大厂及明星AI企业中的薪资竞争力显著提升（部分核心岗位可达较高水平）。
• 门槛提高： “具备AI项目实操经验”正迅速成为简历筛选的重要标准，预计未来1-2年将成为普遍门槛。

与其观望，不如行动！

面对变革，主动学习、提升技能才是应对之道。掌握AI大模型核心原理、主流应用技术与项目实战经验，是抓住时代机遇、实现职业跃迁的关键一步。

01 为什么分享这份学习资料？

当前，我国在AI大模型领域的高质量人才供给仍显不足，行业亟需更多有志于此的专业力量加入。

因此，我们决定将这份精心整理的AI大模型学习资料，无偿分享给每一位真心渴望进入这个领域、愿意投入学习的伙伴！

我们希望能为你的学习之路提供一份助力。如果在学习过程中遇到技术问题，也欢迎交流探讨，我们乐于分享所知。

*02 这份资料的价值在哪里？*

专业背书，系统构建：

• 本资料由我与MoPaaS魔泊云的鲁为民博士共同整理。鲁博士拥有清华大学学士和美国加州理工学院博士学位，在人工智能领域造诣深厚：

• • 在IEEE Transactions等顶级学术期刊及国际会议发表论文超过50篇。
  • 拥有多项中美发明专利。
  • 荣获吴文俊人工智能科学技术奖（中国人工智能领域重要奖项）。

• 目前，我有幸与鲁博士共同进行人工智能相关研究。

内容实用，循序渐进：

• 资料体系化覆盖了从基础概念入门到核心技术进阶的知识点。

• 包含丰富的视频教程与实战项目案例，强调动手实践能力。

• 无论你是初探AI领域的新手，还是已有一定技术基础希望深入大模型的学习者，这份资料都能为你提供系统性的学习路径和宝贵的实践参考，助力你提升技术能力，向大模型相关岗位转型发展。

  

抓住机遇，开启你的AI学习之旅！