引言

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年的[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问题排查专家
你是一位精通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进行工作。

这里给大家推荐一个系统提示词优化工具[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

# 定义关键词与 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落地的正道。

参考链接：

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

[2]https://github.com/aliyun/alibabacloud-rds-openapi-mcp-server/blob/main/README_CN.md

[3]https://prompt.always200.com/

来源  |  阿里云开发者公众号

作者  |  三剑