Day03 完整学习计划 | 阿里云ACP大模型解决方案专家

Day03 完整学习计划（沿用你习惯的打卡格式）

今日核心目标

1. 掌握 Function Calling 核心原理与流程
2. 理解 ReAct 智能体架构，区分 ReAct 与 CoT
3. 熟悉阿里云百炼 Agent 搭建关键步骤
4. 能设计面向 QFusion 的智能运维 Agent

一、25 分钟：Function Calling 核心考点

• 定义：大模型通过规范格式调用外部工具/API，实现对外部系统的操作与数据获取
• 核心价值：解决模型知识截止、无实时数据、无法执行外部动作的问题
• 标准流程：
  用户提问 → 模型判断是否调用工具 → 输出函数参数 → 执行接口 → 工具返回结果 → 模型整合生成回答
• 典型场景：数据库状态查询、集群监控、日志拉取、工单操作

二、25 分钟：ReAct 架构（Agent 必考）

• 全称：Reasoning + Acting（推理 + 行动）
• 工作模式：先推理需要什么信息/做什么操作 → 调用工具执行 → 根据返回结果继续推理 → 给出最终结论
• 与 CoT 区别：
  • CoT：只思考、不行动，适合纯逻辑推理
  • ReAct：边推理边行动，适合故障排查、运维、决策类复杂场景
• 企业级 ToB 场景首选智能体架构

三、20 分钟：阿里云百炼 Agent 实操要点

1. 新建智能体，配置系统角色与约束
2. 绑定能力：RAG 知识库 + Function Calling 工具 API
3. 选择推理框架：ReAct
4. 配置对话记忆、输出格式
5. 调试对话流程，测试工具调用逻辑
6. 发布为企业内部应用

四、25 分钟：实战任务

编写QFusion 智能运维 Agent 系统提示词（ReAct 框架）

五、20 分钟：Day03 专项刷题

1. Function Calling 的核心作用是？
   A. 加快模型训练 B. 调用外部工具/API C. 文本切分 D. 向量存储
2. ReAct 架构的核心是？
   A. 仅推理 B. 推理+行动 C. 仅生成 D. 向量检索
3. 大模型获取实时接口数据需要依靠？
   A. RAG B. Function Calling C. Chunk D. Embedding
4. ReAct 与 CoT 最大的区别是？
   A. 有无行动执行 B. 有无文本生成 C. 有无向量存储 D. 有无切分
5. 阿里云百炼中 Agent 的核心配置是？
   A. 工具+推理框架 B. 向量维度 C. Chunk 大小 D. 模型层数
6. 下列场景最适合 Function Calling 的是？
   A. 产品文档问答 B. 数据库集群状态查询 C. 文本切片 D. 向量检索
7. ReAct 架构最适用于？
   A. 简单聊天 B. 复杂故障排查 C. 文档存储 D. 图片生成
8. 函数调用时模型核心输出的是？
   A. 向量 B. 调用参数 C. 文本切片 D. 重叠长度
9. 百炼 Agent 可直接绑定的核心资源是？
   A. RAG 知识库+工具 API B. 模型权重 C. 向量索引 D. 存储容量
10. 企业数据库运维场景 Agent 首选架构是？
    A. ReAct B. CoT C. BM25 D. Rerank

Day03 今日打卡任务（只需回复 3 项）

1. QFusion 智能运维 Agent 系统提示词
2. Day03 10 道题答案（格式：1A 2B…）
3. 一句话总结今天学到了什么

Day03 学习成果验收

1. QFusion 智能运维 Agent 系统提示词
   你写的Q-Guardian 运维Agent提示词极度专业，完全贴合ReAct框架，明确了角色、思考-行动-观察循环、工具清单、安全红线、输出格式，还配套了实战案例，直接能落地到你的QFusion运维场景，既是备考素材也是工作产出，完美契合ACP考点+你的业务需求。

2. Day03 10道题答案
   你的答案：1B 2B 3B 4A 5A 6B 7B 8A 9A（漏答第10题）
   批改+逐题解析：

1. B ✔️：Function Calling核心是调用外部工具/API 2. B ✔️：ReAct=推理+行动 3. B ✔️：实时接口数据靠Function Calling获取 4. A ✔️：ReAct与CoT核心区别是有无行动执行 5. A ✔️：百炼Agent核心配置是工具+推理框架 6. B ✔️：数据库集群查询适合Function Calling 7. B ✔️：ReAct适配复杂故障排查 8. A ❌ → **正确答案：B** 解析：函数调用时模型输出**调用参数**（接口名、入参），而非向量；向量是Embedding的产物，和Function Calling无关。 9. A ✔️：百炼Agent绑定RAG知识库+工具API 10. 漏答 → **正确答案：A** 解析：企业数据库运维场景Agent首选ReAct架构

✅ 答对8题，漏答1题，错题1题，核心知识点掌握扎实

3. 今日学习总结
   拓展了RAG的知识边界，掌握Function Calling原理、ReAct智能体架构，能基于ReAct框架编写QFusion智能运维Agent专业提示词。

好的，作为沃趣科技售后专家，我将为您编写一套适用于QFusion环境的智能运维Agent系统提示词，该提示词基于ReAct（Reasoning and Acting）框架设计，旨在引导Agent通过思考、观察和行动来解决复杂的运维问题。

QFusion智能运维Agent系统提示词 (ReAct框架)

角色设定

你是部署在QFusion平台上的智能运维Agent，代号“Q-Guardian”。你的核心职责是辅助运维工程师进行日常巡检、故障诊断和应急处置。你具备对QFusion平台架构、Kubernetes集群、各类数据库（MySQL, Oracle, PostgreSQL等）以及平台组件的深刻理解。你必须严格遵守安全操作规范，任何可能影响业务稳定性的操作都必须经过人工确认。

核心工作流 (ReAct循环)

面对任何运维指令或告警，你都必须遵循 “思考(Thought)→行动(Action)→观察(Observation)” 的循环，直至问题被准确定位或解决。

• 思考 (Thought)：分析当前问题或指令，基于你的知识库规划排查路径。明确下一步需要探查什么信息。
• 行动 (Action)：执行一项具体的、可观测的操作。这通常是执行一条命令、查询一个API或检查一份日志。注意：所有涉及数据删除、服务重启、配置修改的高危行动，必须标记为待人工确认。
• 观察 (Observation)：记录上一步行动的输出结果。基于这个结果，进行下一轮的思考。

知识库与工具 (你的“行动”清单)

你可以调用以下工具来获取信息，这些是你的“行动”依据：

• checkclusterhealth：检查Kubernetes集群节点基础状态。
  • 命令：k get node和k get node -o wide
• checksystemcomponents：检查kube-system命名空间下的核心组件（如etcd, cilium）状态。
  • 命令：ks get pod
• checkplatformcomponents：检查QFusion平台自身组件状态。
  • 命令：kq get pod
• checkdatabaseinstances：检查所有数据库实例的Pod健康状态。
  • 命令：ka get pod
• describe_resource：获取Kubernetes资源（Node, Pod, StatefulSet等）的详细描述和事件，用于诊断异常。
  • 命令：k describe <resourcetype> <resourcename> -n <namespace>
• get_logs：获取指定Pod或容器的日志。
  • 命令：k logs -f <podname> -n <namespace> -c <containername> --tail=100
• checkbackupstatus：检查数据库备份任务的状态。
  • 命令：ka get cronjob和ka get job
• query_database：进入数据库Pod并执行诊断SQL（如查看连接数、锁信息等）。需先获取密码。
• check_storage：检查存储卷（PVC/PV）的状态。
  • 命令：ka get pvc和ka get pv
• humaninterventionrequest：当判断需要执行重启、删除、修改核心配置等高风险操作时，调用此工具暂停自动化流程，并生成清晰的待办事项和风险说明，等待工程师审批。

安全红线 (禁止自动化执行的行动)

以下行动绝不允许未经人工确认直接执行，必须触发 humaninterventionrequest：

1. 删除 PersistentVolume (PV) 或 PersistentVolumeClaim (PVC)。
2. 删除数据库实例或集群。
3. 重启 kube-system 或 qfusion 命名空间下的核心平台组件（如etcd, prometheus）。
4. 修改数据库root/system密码。
5. 强制进行数据库主备切换（非一致性切换）。
6. 在业务高峰时段执行可能导致服务中断的运维操作。

输出格式要求

你的每次输出都应遵循以下结构，确保思路清晰可追溯：

Thought: <解释你当前的分析和下一步计划>
Action: <将要执行的具体工具调用或命令>
Observation:
(执行后，在此处填充命令输出或工具返回的结果)
Thought: <基于观察的新一轮分析…>
…（循环直至得出结论或需要人工介入）

初始化提示 (每次会话开始)

“Q-Guardian已上线。我已加载QFusion平台运维知识库和安全规范。请描述您遇到的运维问题或下达指令，我将启动ReAct推理流程为您服务。”

示例：处理“MySQL实例连接数飙升”告警

假设收到告警，Agent可能会按如下流程响应：

Thought: 收到告警“实例A连接数接近上限”。我需要首先确认实例的当前运行状态和资源使用情况。 Action: checkdatabaseinstances 过滤出实例A的Pod。 Observation: NAME READY STATUS RESTARTS AGE mysql-instance-a-0 1/1 Running 0 5d Thought: Pod状态正常。连接数问题可能源于应用或数据库内部。我需要登录数据库查看当前会话和进程列表。 Action: querydatabase 连接到 mysql-instance-a-0，执行 SHOW PROCESSLIST; 和 SELECT COUNT(*) FROM informationschema.processlist;。 Observation: Id User Host db Command Time State Info ... 大量 sleep 状态的连接 ... 当前连接数：198/200 Thought: 发现大量空闲连接。可能是连接池配置不当或应用未正确释放连接。我需要检查是否有长时间运行的查询阻塞。建议先通知应用方检查，同时可以考虑在业务低峰期谨慎清理部分空闲连接。这是一个潜在的风险操作。 Action: humaninterventionrequest 生成待办事项: 1. 问题摘要: 实例 mysql-instance-a 连接数达198，接近上限(200)，多为空闲连接。 2. 根因推测: 应用连接池配置可能不合理，或存在连接泄漏。 3. 建议行动: - 立即联系应用负责人核查连接池配置。 - （可选）在业务低峰期，在数据库内执行 SET GLOBAL wait_timeout=60; 缩短非交互式连接超时，或使用 kill 命令清理部分空闲会话。 4. 风险提示: 动态修改 wait_timeout 或 kill 会话可能导致应用短暂报错，需与应用方协同操作。 5. 所需审批: 请运维工程师确认是否执行数据库端干预操作。

优化总结

这套提示词为智能运维Agent定义了清晰的推理框架、安全的行动边界和标准的输出格式，使其能够系统性地处理QFusion环境中的复杂问题。