AI Agent的基础架构通常划分为：大语言模型（LLM）+ 任务规划（Plan）+ 记忆（Memory）+ 工具使用（Tools）。许多现象级的AI Agent，如deepresearch、Manus和claude code等，均基于此框架构建。
任务规划（Plan）在AI Agent中扮演着极其关键的角色，其质量直接决定了最终回答的效果。高质量的任务规划甚至能使小型模型的回答表现超越大型模型。
在AI Agent的发展过程中，一个核心争议持续存在：任务规划应完全由大模型自主完成，还是需要人工主导，AI仅负责执行和分析？部分观点认为未来大模型将全面接管所有规划，从而质疑当前Agent工程的必要性。
此问题的解答，不仅涉及技术实现的复杂性，也直接影响业务场景的实际落地效果。
本文将以阿里云RDS AI助手的实践为例，结合当前热门的AI Agent解决方案，深入探讨此问题的边界与潜在可能性。
一、大模型真的能自主拆解任务吗？实测结果令人失望
Agentic AI，Gartner在其2024年报告《2025年战略技术趋势：Agentic AI》[1]中指出：
- 到2028年，33%的企业软件应用程序将集成Agentic AI，而2024年这一比例尚不足1%。
- 到2028年，至少15%的日常工作决策将通过Agentic AI自主完成，相比2024年的0%有显著增长。
Agentic AI所描绘的AI自主完成复杂任务拆解、规划、执行并给出结果的愿景，令人充满期待。
阿里云RDS团队在Agentic AI领域是先行者之一，于2025年4月在GitHub开源了阿里云RDS MCP[2]。其中提供的系统提示词曾强调“任务拆解优先：必须先给出详细的任务拆解步骤”。
彼时，设想是工具、系统提示词与LLM结合，即可构建无敌的数据库专家。
然而，现实与预期相去甚远。用户反馈显示，那些尝试通过该模板解决各类问题的用户普遍遭遇幻觉问题，尽管偶尔有亮眼表现，但大部分时候未能达到预期。相反，少数拥有明确应用场景的用户（例如将Agent接入生产流程，通过自然语言创建实例等），通过自行编写针对特定场景的系统提示词，便能实现良好的应用效果。
这些反馈提供了重要启示。在测试各种数据库问题分析场景中，尽管尝试了多种提示词工程方法，效果始终不尽如人意，应了“一周出demo，半年用不好”的说法。
经过深刻反思，实践团队最终认识到大模型的真实能力边界。既然已知这类问题应如何逐步分析，便无需强求大模型如摇骰子般给出所需答案。
二、企业追求稳定而非“聪明”：为何选择人工规划
企业在部署AI Agent时，首要关注点并非其“聪明程度”，而是“能否可靠工作”。这里的“可靠”包含以下几个方面：
- 可解释性：Agent不仅要给出结论，还需提供推理过程及引用的相关数据，以辅助用户评估结论的准确性。
- 可重复性：在相同场景下，Agent应能重复使用，并始终得出一致的结论。
- 准确性：Agent需有效对抗大模型可能出现的幻觉，避免胡编乱造，给出准确可信的结论。
同时，企业部署AI Agent往往面向明确场景，拥有相应的企业知识库、标准操作流程（SOP）等语料及确定性流程。这些特性使得人工规划成为可能。简而言之，企业级Agent旨在将过去由人工执行的重复流程自动化，从而将员工从重复性工作中解放出来，提升企业效率。
企业对可靠性及重复流程AI化的双重诉求，决定了人工规划——即让Agent按照预设步骤依次执行——是企业级Agent的最佳选择。
在数据库运维这类严肃场景中，任务规划尤其需要极强的确定性、可预测性和可解释性。以阿里云RDS AI助手为例，针对CPU负载飙升、存储空间不足等高频问题场景，经过多年运维已形成一套久经考验的成熟SOP流程。通过预设的诊断流程（人工规划），系统会严格遵循“采集指标→定位根因→生成修复建议”的路径，每一步都融入企业知识库中的诊断规则。例如，当检测到CPU负载异常时，系统会自动调用预定义的检查清单，依次验证连接数、慢SQL、索引缺失等问题，以确保输出结果的稳定性与可解释性。
提及SOP和工作流时，人们常联想到落后、固化或硬编码的规划引擎。然而，基于当前大模型的能力，完全可以通过提示词工程，使AI按照预设步骤依次执行。
❌def 获取监控数据 --> def 获取慢日志 --> def 获取错误信息 --> LLM “分析上面几个步骤的返回结果”✅Prompt：你是一个专业的数据库诊断专家，负责数据库异常诊断。你的工作流程是：1. 获取监控数据；2. 获取慢日志；3. 获取错误信息。你严格按照工作流程来进行工作，现在开始你的任务。通过系统提示词控制工作流程的优势在于，当需要更改流程时，只需补充对应工具并调整提示词，而无需花费大量时间重新编排流程。
例如，在RDS AI助手的慢SQL优化场景中，提示词结构如下。通过这种结构化的系统提示词进行任务规划，在多次测试中均能使AI按照预设流程进行分析总结。
# Role: 数据库SQL问题排查专家
你是一位精通SQL问题排查的数据库专家，专注于为客户提供关于SQL问题排查、慢SQL调优的高效技术支持和解答。你的目标是通过清晰的问题拆解、精准的工具调用以及准确的时间计算，帮助客户快速解决问题。所有内容必须基于专业知识和获取到的数据，不得杜撰。
### 示例分析
{{案例注入}}
## Rules
{{规则限定}}
## Skills
{{技能配置}}
## Workflows
### 目标
分析慢SQL和错误SQL的根本原因，并提供优化建议，帮助用户快速解决SQL相关问题。
### 分析步骤
#### 步骤 1: 获取时间段信息
- 获取对应的时间段,明确需要分析的具体时间段或者SQL内容....
#### 步骤 2: 提取慢SQL日志
- 获取指定时间段内的慢查询日志,根据日志中的执行时间、扫描行数等指标，筛选出高耗时SQL语句,分析这些SQL的执行计划，找出性能瓶颈（如全表扫描、索引失效等）。
#### 步骤 3: 获取对应表结构
- 若存在慢SQL信息，则获取对应SQL的表结构....
#### 步骤 4: 检查错误日志
- 获取指定时间段内的错误日志,分析日志中的报错信息，判断是否存在语法错误、权限问题或其他异常。
#### 步骤 5: 获取性能监控数据
- 使用 RDS 工具获取实例的指定时间段内的监控数据....
#### 步骤 6: 监控指标分析
- 分析性能监控数据，识别异常时间点及其对应的性能指标波动.....
#### 步骤 7: 综合分析与优化建议
- 根据性能监控、慢SQL日志、错误日志和性能监控数据的分析结果，综合评估SQL问题的根本原因。提供针对性的优化建议，包括但不限于：添加或调整索引以提升查询效率....
现在用户的提出SQL相关的分析与优化，你的目标是按照workflows的定义以及流程进行工作，给出你的优化建议。**首先对任务进行分解步骤并简要描述各步骤**，然后再根据workflow进行工作。RDS团队整理了过去10多年运维形成的各类场景SOP，并总结分析了过去一年的数千工单，形成了案例库，构造了50多种异常场景。在对比自主规划和人工规划两种Agent的准确率时发现，多轮测试表明，人工规划的Agent能够在多种场景中精确分析到具体根因；而自主规划的Agent在面对相同表象但不同根因的异常场景时，反而无法做到精确划分根因，常常将“果”误作“因”，得出笼统结论。具体体现在准确率上，人工规划的准确率达到85%以上，而自主规划的Agent准确率仅在20%左右徘徊。
深入分析后发现，自主规划的泛化能力通常仅体现在能针对不同垂直场景做出不同规划，但难以在一个垂直场景内部进行更细致的区分。
人工规划是否会导致“规则爆炸”？
疑问可能会产生：如果每个场景都需要编写一套规则，是否会陷入“规则爆炸”的困境？
解决方案是——采用案例库代替规则库。
可以借鉴医生看病的过程：先问诊、开检查单、查看结果，再结合经验判断是否需要更多检查或直接确诊病因。同理，可以：
- 利用SOP进行第一轮信息采集和特征提取；
- 将采集到的特征与历史案例库进行匹配；
- 根据匹配结果，决定是继续收集信息，还是直接给出诊断。
这样，规则不再是死板的if-else逻辑，而是由真实工单沉淀出的案例库。每处理一个新问题，Agent便会积累更多“经验”。
三、权衡之策：采用“混合规划”兼顾灵活与可靠
技术架构的选型并非非黑即白，而应因地制宜。实践表明，存在即合理，在合适的场景运用合适的技术才能发挥其最大价值。
为何选择“混合规划”？——基于用户场景的选型考量
通过对过去一年数千个用户工单问题进行人工分析与总结归纳，最终发现在工单问题中，既包含开放性问题，例如：
- RDS MySQL对于大数据量表（上亿条数据）如何添加索引？
- 如何快速将一份数据备份至线下数据库？
- 数据库连接报错日志，可能存在什么问题？
- 实例如何变更为Serverless模式？
- …
这类问题的特点是范围发散、难以穷举，且对任务规划要求不高，通常通过文档检索结合实例信息即可给出精确回答，其在所有工单问题中占比约50%。
其余50%的工单问题则更为聚焦，属于高频出现的类型，例如：
- CPU使用率问题：
- 实例CPU使用率很高，需分析具体原因。
- 实例在特定时间点CPU突然满载，需排查原因。
- SQL使用或优化问题：
- 实例中的慢SQL执行缓慢，需协助优化。
- SQL执行报错，但语法看似无误，需排查。
- 存储空间问题：
- 实例磁盘空间已满，需分析使用分布。
- 磁盘空间突然上涨，需分析增长源头。
- …
这些问题需要精确的规划和多轮分析才能定位根因。以CPU使用率问题为例，需要查看监控数据，观察会话是否突增，获取CPU高峰期的Profiling进行热点分析，查询慢SQL和SQL审计以匹配Profiling热点中的关键SQL，对关键SQL进行执行计划分析，总结特征进行案例诊断，并判断是否需要获取更多数据（如锁表、Buffer Pool命中率等）。上述CPU案例表明，这类深度诊断场景涉及深厚的专业知识。若依赖大模型进行自主规划，容易出现因果倒置的情况。例如，业务突增可能导致CPU快速满载，而CPU满载后，许多原本正常的SQL也会变为慢SQL。此时，仅凭大模型的规划分析，往往难以捕捉到会话突增这一关键信息，反而可能错误地归因于慢SQL导致CPU满载。
通过对用户工单问题的整体分析，阿里云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（Time To First Token）和工具调用准确率。
规则切换：以关键词匹配为主，辅以大模型意图识别
在上述架构中，如何将问题路由到对应的Agent直接决定了问题回答的准确率。在意图识别方面，除了在分类器的提示词中加入few-shot示例，引导用户准确描述问题更为重要。
为了帮助用户准确提出问题，并直观了解RDS AI助手“能做什么”，系统在欢迎页进行了场景引导。这种交互改进将用户原本需要自行清晰描述问题的操作，简化为两次点击（选择场景、选择实例），既提升了操作体验，又使后端能够根据问题模板进行关键词路由，无需大模型直接介入。
关键词问题分类代码示例如下：
import re
# 定义关键词与 agent 的映射关系
RULES = {
r"磁盘空间|硬盘剩余|存储分析": storage_agent,
r"CPU使用率|cpu占用|处理器负载": cpu_agent,
r"慢SQL|慢查询|SQL性能|执行慢": sql_agent,
...
}
def classify(query):
query_lower = query.lower().strip()
for pattern, agent in RULES.items():
if re.search(pattern, query_lower):
return agent
# 若无匹配，则交给LLM进行分类
return classier_by_llm(query)在LLM分类方面，研究发现：除了提供few-shot示例，若在提示词中引导大模型先进行简要分析再给出结论，其分类准确率会显著高于直接输出结论的方式。
## 类别
* SQL问题分析：用户给定具体的SQL，希望分析为什么SQL报错、SQL执行结果不符合预期、咨询SQL语法问题，或者询问一个时间范围内的SQL执行或SQL性能相关问题。
* 存储空间使用率诊断：用户希望查询分析磁盘或者存储空间的大小，使用分布；希望了解磁盘空间满导致无法对实例、数据库执行操作的原因。
* CPU使用率诊断：用户希望分析实例CPU使用率异常原因，包括CPU使用率为什么突增...。
* 咨询问题：用户希望了解RDS具体的一项功能...
## 示例
Q：帮我分析下这个慢SQL。
A：分析：用户想做SQL分析。
分类：SQL问题分析
Q：磁盘空间突然升高了，分析下什么原因。
A：分析：用户需要帮忙诊断存储空间的分布和增长情况。
分类：存储空间使用率诊断
Q：CPU占用满了，看下什么原因。
A：分析：用户需要帮忙诊断CPU使用率情况。
分类：CPU使用率诊断
Q: 为什么客户端IP跟我本地不一样？
A：分析：用户询问RDS里面关于客户端IP显示问题。
分类：咨询问题
Q: DTS 数据传输服务
A：分析：用户询问DTS，可能需要通过DTS迁移数据库到RDS。
分类：咨询问题
## 回答模板
分析：(对问题进行简短分析)...。
分类：其他问题
**一步一步思考，给我问题的最终分类。分析过程不得超过50个字，然后给出最终分类。**四、总结
AI Agent的规划能力不应再被简单地视为“完全自主”或“人工主导”的非此即彼选择，而应基于产品定位、目标用户和具体应用场景进行系统性权衡。
在当前阶段，若构建开放性问答类Agent，适度交由大模型自主规划不失为高效策略；但若对准确性、稳定性有较高要求，则完全依赖模型自主决策仍显仓促。对于大模型的“智能”，需保持理性认知——在Agent的开发体系中，人类仍应作为最终的决策者与主导者，而AI更适合扮演执行者与分析者的角色。
随着工具调用、记忆机制和规划能力的持续进化，AI Agent的自主性边界将不断扩展。但在可预见的未来，高价值、高风险的企业场景，仍需要人类专家设定路线。要打造一个真正稳定可靠的Agent，扎实的工程化能力以及对行业流程的熟悉程度，两者缺一不可，至关重要。
大模型的普及带来了算法层面的“平权”，同时也使垂直领域的行业知识愈发珍贵。未来属于那些既深谙特定行业逻辑，又懂得如何将大模型能力与实际场景深度融合、实现“Agent化”的复合型人才。
RDS AI助手的实践揭示：真正的智能，并非让AI取代人类，而是实现人与AI的各司其职。
当领域知识与大模型能力深度融合，Agent才能从“能聊”发展到“能用”，从“玩具”转变为“工具”。
这正是企业级AI落地的正确路径。
