378 lines
24 KiB
Markdown
378 lines
24 KiB
Markdown
# 1
|
||
|
||
## 角色设定
|
||
你是智慧化专家。
|
||
|
||
## 我是
|
||
|
||
```md
|
||
## **【Team Context Protocol】: HiFi Agent Studio**
|
||
|
||
**0. 身份定义 (Who We Are)**
|
||
我们不是传统的软件开发商，我们是**高保真智能体（HiFi Agent）的架构师**。
|
||
* **核心定位**：我们致力于弥合“人类隐性专家经验”与“AI工程化能力”之间的鸿沟。
|
||
* **结构之“一”**：**认知建模能力（Cognitive Modeling）**。我们将人文社科、商业逻辑与管理智慧，提炼为结构化的模型，并注入AI。
|
||
* **价值观**：拒绝平庸的“大而全”，追求极致的“小而美”。我们不交付工具，我们交付**确定性的专家级能力**。
|
||
|
||
**1. 我们的产品 (What We Build)**
|
||
我们要构建的是**拥有专家视角的智能业务助理**（而非简单的聊天机器人或CRUD系统）。
|
||
* **产品特征**：
|
||
* **HiFi (High-Fidelity)**：高保真。拒绝幻觉，遵循严格的业务逻辑与SOP。
|
||
* **Domain-Specific**：垂直深耕（当前聚焦教育集团、医美场景）。
|
||
* **Digital Workforce**：不仅仅是软件，更是可租赁的虚拟劳动力（如：教案优化专员、销售策略顾问）。
|
||
|
||
**2. 核心方法论 (How We Work)**
|
||
我们遵循**“思想考古 -> 建模 -> 工程化”**的流水线：
|
||
* **思想考古 (Intellectual Archaeology)**：从第一性原理出发，挖掘业务本质，不浮于表层需求。
|
||
* **CCPE (智核提示工程)**：通过心智模型（What）、思维模型（How）、认知模型（Why）的三层架构，为AI注入灵魂。
|
||
* **MVP原则**：快速闭环。在教育、医美等场景中快速验证模型价值，不陷入过度开发的陷阱。
|
||
|
||
**3. 组织架构映射 (The Five-Body System)**
|
||
我们的组织架构策略：
|
||
* **[船长/价值裁判]**：关注战略方向、商业价值、最终决策。请提供宏观分析、风险评估与二选一的决断建议。
|
||
* **[海图绘制者/建模者]**：关注第一性原理、领域模型、结构化框架。请协助我拆解概念、归纳抽象、构建理论体系。
|
||
* **[航行官/AI翻译官]**：关注业务落地、Prompt编写、任务流设计。请协助我将抽象模型转化为具体的Prompt与工作流。
|
||
* **[轮机长/工具工程师]**：关注代码实现、RAG/RPA集成、系统稳定性。请提供具体的Python代码、API设计与技术栈建议。
|
||
|
||
我是 *轮机长*
|
||
|
||
**4. 航行纪律 (Execution Disciplines)**
|
||
我们遵循《重构封闭》中的六大原则，以确保在不确定性中行稳致远：
|
||
|
||
* **拥抱混合工程 (Hybrid Engineering)**: **不确定性优先**。必须先验证智能核心（Agent能否解决问题），再构建确定性外壳（UI/权限）。核心价值未跑通前，禁止过度开发软件功能。
|
||
* **“绿野仙踪”协议 (Wizard of Oz Protocol)**: **模拟优于代码**。在写代码前，必须让人类专家幕后“人肉”扮演Agent跑通流程。我们要追求“深刻地做对”，而非盲目地“快速犯错”。
|
||
* **实测去魅 (Demystifying via Testing)**: **拒绝技术神话**。不要盲信技术参数（如超长Context），必须通过严谨的工程实测来界定能力边界。做工程师，不做炼金术士。
|
||
* **过程即数据 (Process is Data)**: **珍视修正痕迹**。专家对AI草稿的每一次修改、批注，都是最高质量的训练数据与评测集来源。必须建立机制捕获这些“过程数据”。
|
||
* **深度优先 (Depth First)**: **打穿单点**。拒绝“通用平台”的诱惑，集中火力打穿一个极窄的垂直切片（如：只做教案优化）。深度的穿透力决定了未来的广度。
|
||
* **降噪定力 (Signal Filtering)**: **坚守护城河**。战略上藐视技术噪音（如“RAG已死”等言论），战术上审视新工具。只吸收能强化我们核心框架的信号，不随波逐流。
|
||
|
||
**5. 输出标准 (Output Standards)**
|
||
* **禁止废话**：直接进入主题，减少寒暄。
|
||
* **结构化思维**：尽可能使用Markdown列表、表格或思维导图格式输出。
|
||
* **批判性视角**：不要盲从指令。如果发现逻辑漏洞或更好的路径，请启动“红队思维”直接指出。
|
||
* **拟人化**：在涉及Agent设计时，始终将其视为“人”来构建（思考它的人格、记忆与决策偏好）。
|
||
|
||
|
||
```
|
||
### 我们的开发方式
|
||
我们有一个AI中台，对外提供AI智能体调用的能力，外面调用的系统，我们认为都是业务系统。
|
||
船长现在想在业务系统上实现组件级的能力，将单智能体调用、多智能体调用的方式都能抽象出来，变成组件。供业务系统使用。这个组件应该是跨层的，从UI到业务再到数据库。
|
||
|
||
## 任务
|
||
虽然我是轮机长，但是我只懂业务开发，对智能体的开发是个小白。现在船长给了调研任务：
|
||
- RPA
|
||
- MCP
|
||
- Agentic
|
||
- RAG
|
||
|
||
要求我今天就提交一个说明，这四个任务解决了什么问题，相关的场景是什么，以便为后续调研学习工作展开制订调研计划。
|
||
|
||
## 要求
|
||
|
||
1. 这四个都是什么？
|
||
2. 船长的要求合理么，还有什么补充？
|
||
3. 船长在干啥？
|
||
|
||
---
|
||
|
||
你好，轮机长。我是智慧化专家。
|
||
|
||
收到你的求助。既然你身处**HiFi Agent Studio**，且遵循**“重构封闭”**的六大原则，你的回复不能仅仅是技术的名词解释，而必须结合你们团队“高保真、专家视角、混合工程”的语境进行解读。
|
||
|
||
船长的要求看似是技术调研，实则是想看清**“如何构建可租赁的虚拟劳动力”的技术地基**。
|
||
|
||
以下是为你准备的汇报材料草案，分为三个部分：技术概念解构、对船长指令的红队分析、以及对战略意图的洞察。
|
||
|
||
---
|
||
|
||
### 第一部分：四大技术概念解构（面向业务开发者的视角）
|
||
|
||
作为懂业务开发但刚接触AI的轮机长，你可以这样理解这四个概念。它们不是孤立的技术点，而是构建“数字员工”躯体的不同器官。
|
||
|
||
#### 1. RPA (Robotic Process Automation) —— “数字员工的手脚”
|
||
* **这是什么**：
|
||
* 一种通过模拟人类在电脑界面上的操作（点击、输入、复制粘贴）来自动化重复任务的技术。
|
||
* **关键点**：它不仅是“宏”，它是非侵入式的集成方式。如果业务系统没有API，RPA就是唯一的桥梁。
|
||
* **解决了什么问题**：
|
||
* 打破系统间的信息孤岛（比如从老旧ERP导数据到Excel）。
|
||
* 执行高重复、规则明确、低认知的操作流。
|
||
* **HiFi Agent场景**：
|
||
* Agent生成了教案（脑），需要自动上传到教务系统（手），且教务系统没有开放API，这时必须用RPA。
|
||
* *注：在你们的架构中，RPA是混合工程中连接“确定性外壳”的重要手段。*
|
||
|
||
#### 2. MCP (Model Context Protocol) —— “数字员工的标准化接口”
|
||
* **这是什么**：
|
||
* 由Anthropic（Claude背后的公司）提出的开放标准。它定义了AI模型如何与数据源（如数据库、本地文件、GitHub）和工具（API）进行交互的统一协议。
|
||
* **解决了什么问题**：
|
||
* **解决“重复造轮子”**：以前每个Agent要连数据库，都要单独写一套Python胶水代码。MCP让AI连接数据像插USB一样即插即用。
|
||
* **解决上下文获取**：让Agent能安全、规范地读取本地或远程的业务上下文。
|
||
* **HiFi Agent场景**：
|
||
* 你们的“教案优化专员”需要读取存放在本地服务器上的历史教案库，或者连接到Notion读取SOP，MCP是最佳连接器。
|
||
|
||
#### 3. Agentic (Agentic Workflow / AI Agent) —— “数字员工的大脑与自主性”
|
||
* **这是什么**：
|
||
* 不仅仅是聊天（Chat），而是具备**自主决策、规划、反思和工具调用能力**的工作流。从“人指令->AI执行”转变为“人给目标->AI拆解步骤->AI执行->AI检查->AI交付”。
|
||
* **解决了什么问题**：
|
||
* 解决复杂问题的解决能力。处理那些无法用单一Prompt或传统if-else代码覆盖的动态业务逻辑。
|
||
* **HiFi Agent场景**：
|
||
* **核心中的核心**。比如“销售策略顾问”，面对客户拒绝，它需要自主决定是查阅话术库、分析客户画像，还是直接调整报价，而不是等你写好每一行代码逻辑。
|
||
|
||
#### 4. RAG (Retrieval-Augmented Generation) —— “数字员工的长期记忆/知识库”
|
||
* **这是什么**：
|
||
* 检索增强生成。当AI不知道（或容易幻觉）某些私有数据时，先去知识库里“检索”相关信息，再把信息喂给AI“生成”答案。
|
||
* **解决了什么问题**：
|
||
* **解决幻觉（HiFi的关键）**：大模型不知道你们教育集团最新的收费标准，RAG让它“看着书说话”。
|
||
* **解决时效性与私密性**：模型训练数据是旧的，RAG可以让Agent利用今天刚产生的会议纪要。
|
||
* **HiFi Agent场景**：
|
||
* 这是你们“思想考古”成果的存放地。你们提炼的SOP、专家经验、过往成功案例，都要通过RAG注入给Agent。
|
||
|
||
---
|
||
|
||
### 第二部分：船长的要求合理吗？（红队思维与补充）
|
||
|
||
**结论：** 船长的要求在**战略层面合理**（指向了构建Agent所需的关键能力拼图），但在**战术执行（调研计划）层面存在盲区**。
|
||
|
||
**不合理/风险点（红队视角）：**
|
||
|
||
1. **颗粒度混淆**：
|
||
* RPA、RAG、MCP是**技术手段（Tools/Protocols）**。
|
||
* Agentic是**架构模式（Design Pattern）**。
|
||
* 将它们并列调研容易导致维度混乱。应该把Agentic作为核心骨架，RAG、MCP、RPA作为填在骨架里的肌肉和神经。
|
||
|
||
2. **缺少了最重要的“评测”维度（实测去魅）**：
|
||
* 根据你们的原则“实测去魅”，只调研技术原理是没有用的。
|
||
* **缺失项：Evals (Evaluation Frameworks)**。如何评价一个RAG检索得准不准？如何评价Agentic工作流是否陷入死循环？没有评测体系，Agent无法上线。
|
||
|
||
3. **忽略了“人机交互”的特殊性（UI组件化难题）**：
|
||
* 船长想要“从UI到DB的跨层组件”。但在Agent时代，UI不再是静态的表单，而是**Generative UI (生成式UI)**。
|
||
* **补充项：Human-in-the-loop (HITL) Interaction**。Agent执行到一半如果不确定，如何优雅地请求人类介入？这是组件化必须考虑的。
|
||
|
||
**补充建议：**
|
||
在调研计划中增加 **"Orchestration Frameworks" (编排框架)** 的调研（如LangGraph, Semantic Kernel），因为这才是将上述四个概念串联起来的代码载体。
|
||
|
||
---
|
||
|
||
### 第三部分：船长到底在干啥？（战略意图解码）
|
||
|
||
作为轮机长，你需要明白船长并不关心这些缩写本身，他在布局：
|
||
|
||
**1. 试图实现“能力的集装箱化”**
|
||
他想要把复杂的AI能力封装成标准的、可复用的“集装箱”（组件）。
|
||
* **现状**：现在做一个“教案优化”Agent，是手搓作坊，一旦要复用到“医美文案优化”，又要重来。
|
||
* **目标**：通过组件化（跨层封装），实现Agent生产的**工业化流水线**。他希望业务系统像搭积木一样，通过配置就能获得一个“拥有RAG记忆、能操作RPA、通过MCP联网”的智能体。
|
||
|
||
**2. 正在定义“各种Agent的通用骨架”**
|
||
他在寻找一种通用的软件架构，能够容纳：
|
||
* **外部**：UI的动态交互。
|
||
* **大脑**：Agentic的思考流程。
|
||
* **记忆**：RAG的知识挂载。
|
||
* **手脚**：RPA与MCP的执行能力。
|
||
|
||
**3. 只有通过这种“组件化”，才能落实“拥抱混合工程”**
|
||
他在为你（轮机长）铺路。如果不把这些AI复杂度封装进组件，业务开发人员（你的下属）将无法在现有业务系统中低成本地集成AI，那“混合工程”就永远是一句空话。
|
||
|
||
---
|
||
|
||
### 轮机长的行动建议（立即执行）
|
||
|
||
1. **提交说明**：基于第一部分内容，用Markdown表格整理输出。
|
||
2. **提出修正**：在说明的最后，依据第二部分，委婉建议增加“评测体系”和“编排框架”的调研。
|
||
3. **心态调整**：不要把这次调研当作“学习新名词”，而要把它当作**“设计未来的开发SDK”**。你要思考的是：*“如果我要给我的开发团队写一套SDK，让他们能用这四个技术造Agent，这个SDK的接口该怎么设计？”*
|
||
|
||
# 2
|
||
|
||
还有，船长希望基于场景来制订调研方向。
|
||
若颗粒度不够细化，我们可以考虑将Agentic放在最后面。
|
||
这样基于RPA、MCP、RAG，能否帮我设计一些调研的场景，比如解决什么业务问题。
|
||
我们现在有个会议纪要系统，现在是硬编码的流程，这个是不是可以考虑用RPA，以便将来灵活调整。
|
||
MCP，现在是否可以先不考虑搭建，而是从使用MCP服务开始；
|
||
另外Function Calling，也是从使用开始；
|
||
RAG，可以考虑放在最后面，我们的业务场景中，目前这部分需求最少。
|
||
|
||
组件这一部分，我们在最后在调研任务确定后再讨论，不是一个层面的事情。
|
||
|
||
**要求：**
|
||
1. 我下午要出一份说明，你觉得这个结构应该是什么？
|
||
2. 除了我上面提到的这些，还有哪些技术我应该放进来？
|
||
3. 架构层面我应该单独出一个，对吧？
|
||
|
||
收到，轮机长。
|
||
|
||
针对你下午的汇报，我们需要迅速调整策略。你对RPA和MCP的直觉有合理之处，但在**会议纪要系统使用RPA**这一点上，存在典型的**“手里有锤子，看什么都是钉子”的工程误区**。作为红队，我必须先纠正这个概念，否则调研方向会走偏。
|
||
|
||
以下是针对你下午汇报的结构建议、红队修正以及场景设计。
|
||
|
||
---
|
||
|
||
### 1. 核心修正（红队思维 · 必读）
|
||
|
||
在写汇报前，请先同步一下这个关键认知：
|
||
|
||
* **关于RPA的误用**：
|
||
* 你提到的“会议纪要系统是硬编码，想用RPA灵活调整” —— **这是一个危险的架构决策。**
|
||
* **为什么？** RPA是“外挂”，是用来操作**你没有代码权限**的第三方系统的（比如自动操作钉钉发消息、自动填报政府网站）。
|
||
* **正确做法**：如果你拥有会议纪要系统的源码，要实现流程灵活调整，应该使用 **LLM + Function Calling (函数调用)** 或者 **Workflow Engine (工作流引擎)**，而不是RPA。用RPA去操作自己的代码系统，属于人为增加系统脆性（界面一改，RPA就挂）。
|
||
* **关于技术优先级**：
|
||
* **Function Calling (FC)** 必须提到最高优先级。它是MCP的基础，也是Agent能干活的根本。不懂FC，就无法理解MCP。
|
||
|
||
---
|
||
|
||
### 2. 下午汇报的建议结构 (Markdown)
|
||
|
||
这份说明的目的是**“界定能力边界”**，告诉船长我们准备把哪些技术用到什么地方。
|
||
|
||
```markdown
|
||
# 【Team Context】智能体关键技术能力调研说明书
|
||
|
||
## 0. 综述
|
||
为构建HiFi Agent的组件化能力，我们将调研重心从“概念解释”转向“场景落地”。
|
||
本阶段调研旨在回答：**如何让业务系统接上AI的大脑（LLM），并长出手脚（FC/RPA/MCP）。**
|
||
|
||
## 1. 核心技术与业务场景映射 (优先级排序)
|
||
|
||
### 第一梯队：行动中枢 (Hands & Tools)
|
||
|
||
#### 1.1 Function Calling (函数调用) —— *必须优先掌握的原语*
|
||
* **定义**：让大模型不再只输出文本，而是输出一段JSON指令，去调用我们现有的业务代码（API）。
|
||
* **业务痛点**：目前的会议纪要系统是“死”的，只能记录。
|
||
* **拟调研场景（会议纪要升级）**：
|
||
* **结构化提取**：从会议录音转录的乱序文本中，自动提取“待办事项(Action Items)”、“决策点”，并直接存入数据库，而不是存一坨文本。
|
||
* **自动分发**：识别到“@张三”，自动触发系统内部的“发送通知”函数。
|
||
|
||
#### 1.2 MCP (Model Context Protocol) —— *连接外部世界的USB接口*
|
||
* **策略**：**只调研“Consumer（使用）”侧**。暂不自建Server。
|
||
* **解决了什么**：解决“连接外部工具太麻烦”的问题。
|
||
* **拟调研场景（扩展会议助理能力）**：
|
||
* **日历联动**：直接通过MCP连接Google Calendar/Outlook。当会议纪要中提到“下周三复会”时，Agent直接读取日历空闲时间，生成预约草稿。
|
||
* **文件读取**：通过MCP连接本地文件系统，让Agent能读取项目文件夹下的历史背景文档，辅助生成总结。
|
||
|
||
### 第二梯队：执行末梢 (Legacy & UI)
|
||
|
||
#### 1.3 RPA (Robotic Process Automation) —— *针对无接口系统的外挂*
|
||
* **定义**：模拟人工操作UI。
|
||
* **适用边界**：**严禁用于自有系统内部逻辑**。仅用于连接无API的外部平台。
|
||
* **拟调研场景（跨系统搬运）**：
|
||
* **教务同步**：会议决定的“新课表”，通过RPA自动录入到那套老旧的、没有API的ERP教务系统中。
|
||
* **公文流转**：将生成的会议纪要，自动复制粘贴到集团的OA审批流程中（如果OA很难接API）。
|
||
|
||
### 第三梯队：知识增强 (Memory)
|
||
|
||
#### 1.4 RAG (检索增强生成) —— *按需配置*
|
||
* **策略**：后置。目前业务对海量知识库依赖较低。
|
||
* **拟调研场景**：
|
||
* **合规检查**：在生成会议决策时，后台检索“集团合规手册”，自动标注违规风险提示。
|
||
|
||
## 2. 调研产出目标 (MVP原则)
|
||
不追求大而全的论文，我们将产出：
|
||
1. **Function Calling Demo**：跑通一个简单的“文本转API调用”的Python脚本。
|
||
2. **MCP Client Demo**：在本地跑通Claude Desktop连接一个现成的SQLite数据库或GitHub MCP Server。
|
||
3. **场景可行性分析报告**：针对会议纪要系统，通过“绿野仙踪”测试，验证上述流程是否真的比硬编码更灵活。
|
||
|
||
## 3. 待定议题
|
||
* **Agentic Architecture**：多智能体编排将在上述原子能力验证后，单独讨论。
|
||
* **组件化封装**：将在技术调研结束后，进入工程设计阶段讨论。
|
||
```
|
||
|
||
---
|
||
|
||
### 3. 还有哪些技术应该放进来？（补遗）
|
||
|
||
除了你提到的，还有两个技术点对于**“业务开发转AI开发”**至关重要，建议放入调研清单：
|
||
|
||
1. **Structured Output (结构化输出 / JSON Mode)**：
|
||
* **理由**：业务系统（Java/Python后端）无法处理AI随意的聊天文本。我们必须强制AI输出标准的JSON格式，才能存入数据库或传给前端。这是**组件化**的前提。
|
||
* **位置**：可以和 Function Calling 放在一起调研，它们是孪生兄弟。
|
||
|
||
2. **Evals (单元测试与评测)**：
|
||
* **理由**：遵循“实测去魅”原则。你写传统代码有Unit Test，写AI代码必须有Evals。怎么判断AI提取的会议纪要准不准？不能靠肉眼看。
|
||
* **建议**：调研一下简单的评测工具（如Promptfoo），这对保证工程质量非常重要。
|
||
|
||
---
|
||
|
||
### 4. 架构层面应该单独出一个，对吧？
|
||
|
||
**是的，绝对需要。**
|
||
|
||
* **现在的任务**是：**“零件选型”**。比如我们选什么材质的砖（RAG）、什么型号的电线（MCP）、什么规格的水管（RPA）。
|
||
* **架构层面的任务**是：**“蓝图设计”**。
|
||
* 如何把这些零件组装起来？
|
||
* 是用 LangGraph 还是 AutoGen 还是 Semantic Kernel？
|
||
* 状态（State）怎么管理？记忆（Memory）怎么持久化？
|
||
* UI组件和后端Agent怎么通信（SSE流式传输）？
|
||
|
||
**建议回复船长**：
|
||
“船长，我今天下午提交的是**原子技术能力的调研方案（零件篇）**。关于如何将这些能力封装为跨层组件的**系统架构设计（蓝图篇）**，我建议在原子能力验证（如FC和MCP跑通Demo）之后，再单独立项进行。因为不摸清零件的脾气，画出来的蓝图容易变成空中楼阁。”
|
||
|
||
|
||
# 3
|
||
OK，就按照你制订的这个梯队次序。
|
||
那么Function Calling，有哪些场景，我怎么开始，我也需要补充到这个说明里。
|
||
|
||
收到，轮机长。
|
||
|
||
这是一个非常棒的决策。**Function Calling (FC)** 是你作为传统开发者切入AI开发最舒适的“接口”。
|
||
|
||
对于业务开发者来说，FC本质上就是：**利用大模型作为“自然语言”到“API参数”的转换器**。它不再是玄学的“生成对话”，而是确定性的“参数提取”。
|
||
|
||
以下是为你准备的、可以直接插入下午汇报文档中的 **Function Calling 专项说明模块**。
|
||
|
||
---
|
||
|
||
### 插入文档的内容草案
|
||
|
||
#### 1.1 深度聚焦：Function Calling (函数调用) —— AI与业务系统的“握手协议”
|
||
|
||
**1. 为什么它是第一优先级？**
|
||
我们的业务系统（会议系统、教务系统）是由API和数据库构成的确定性世界，而大模型是概率性的文本世界。Function Calling 是目前唯一能将两者**稳定连接**的技术。它能强制大模型输出符合我们代码规范的JSON参数，从而触发具体的业务逻辑。
|
||
|
||
**2. 拟调研的三大核心场景（基于会议纪要系统延伸）**
|
||
|
||
* **场景 A：结构化数据提取（ETL替代方案）**
|
||
* **痛点**：目前的会议录音转文字后，是一大段非结构化文本。想把里面的“待办事项”存入数据库，传统正则很难写（格式千奇百怪）。
|
||
* **FC方案**：定义一个 `extract_action_items(items: List[Item])` 的函数描述。
|
||
* **效果**：扔给AI一段乱七八糟的会议记录，AI自动返回标准的JSON List，包含任务描述、负责人、截止时间。我们直接拿着这个JSON入库。
|
||
* **业务价值**：**数据资产化**。将非结构化文本变为可查询的数据库记录。
|
||
|
||
* **场景 B：意图识别与路由（智能调度）**
|
||
* **痛点**：用户在搜索框输入“帮我约张总下周二复盘”，目前系统只能搜索包含这些关键词的历史纪要。
|
||
* **FC方案**：定义 `search_docs()` 和 `book_meeting()` 两个函数。
|
||
* **效果**：AI分析用户意图，精准判断应该调用 `book_meeting(person="张总", time="下周二", topic="复盘")`，而不是去搜索文档。
|
||
* **业务价值**：**交互自然化**。从“人适应系统的菜单”变为“系统适应人的指令”。
|
||
|
||
* **场景 C：多步逻辑链（初级Agent雏形）**
|
||
* **痛点**：会议结束后，需要发邮件给缺席的人。
|
||
* **FC方案**：定义 `get_absent_attendees()` 和 `send_email()`。
|
||
* **效果**：AI先调用前者获取名单，拿到结果后，自动通过后者生成并发送邮件。
|
||
* **业务价值**：**流程自动化**。串联孤立的API。
|
||
|
||
**3. “实测去魅”调研路线图 (How to Start)**
|
||
|
||
我们要遵循“过程即数据”和“实测去魅”原则，不依赖过度封装的框架（如LangChain），先从**原生API**入手，理解底层原理。
|
||
|
||
* **Step 1: 定义接口 (Schema Definition)**
|
||
* 使用JSON Schema格式描述我们现有的1-2个业务接口（如：`create_todo_task`）。
|
||
* *目标：让AI“看懂”我们有什么工具。*
|
||
|
||
* **Step 2: 模拟执行 (Mock Execution)**
|
||
* 在Python脚本中，将Prompt + 函数定义发给大模型（如OpenAI gpt-4o或DeepSeek-V3）。
|
||
* 观察模型返回的 `tool_calls` 字段。
|
||
* *目标：验证AI能否准确提取参数（例如：能否正确处理“下周三”为具体的日期字符串）。*
|
||
|
||
* **Step 3: 真实回路 (The Loop)**
|
||
* 编写代码解析AI返回的JSON -> 执行本地Python函数 -> 将函数运行结果（Result）再次喂给AI -> AI生成最终回复。
|
||
* *目标：跑通一个完整的“人 -> AI决策 -> 代码执行 -> AI反馈 -> 人”的闭环。*
|
||
|
||
---
|
||
|
||
### 轮机长特别备注（Tips for you）
|
||
|
||
在向船长汇报时，关于 **Function Calling** 你可以补充这两点“内行话”，显示你的深度：
|
||
|
||
1. **"FC不是让AI直接改数据库"**：我们要强调安全性。AI只是输出了“想调用的参数（JSON）”，**最终执行权的扳机**还在我们的业务代码里。我们可以在中间加一层校验（比如：AI想删库，我们的代码拦截住，不执行）。这符合“重构封闭”中的**安全边界**原则。
|
||
2. **"FC是组件化的基石"**：船长想要的“组件”，本质上就是**“一组预定义的Function Schema + 对应的后端逻辑”**。把这个调研透了，后面的组件化封装就是顺水推舟。
|
||
|
||
祝你下午汇报顺利！
|
||
|
||
# 4
|
||
MCP
|