基本概念

1.工作流 (Workflow) 与 Agent 的异同

Workflow（工作流）：

在 Java 生态中，Workflow 的本质是有限状态机 (FSM) 的高级抽象。无论是传统的 Activiti/Flowable，还是现代的分布式工作流引擎 Temporal，其核心逻辑都是预定义的。

• 技术本质：它是 Graph-based 的。开发者在编码阶段就定义好了 $Next = f(State, Input)$。
• 工程优势：
  • 幂等性与重试机制：由于路径确定，我们可以轻松实现节点级别的事务回滚（Saga 模式）或断点续传。
  • 可观测性：每一个 State 的流转都在数据库中有明确记录，审计和排障极其简单。
• Java 类比：就像是一个严谨的 Switch-Case 逻辑或 Chain of Responsibility（责任链模式），虽然复杂，但永远在控制之中。

然后比如我们常用的langgraph，Spring AI alibaba graph这些都是基于工作流的。是智能体早期的一个实现。就是相当于把AI作为我们平常链路的一个部分，去调用了下API做推理的任务

然后在工作流框架里面，最重要的就是建立一套有向无环图 DAG，然后就是记录节点之间的State，然后在我们的不同的节点作为input输入，记录他的output是什么。缺点是比较确定，不够智能。优点是更加工程化，调控的粒度更加细。

Agent（智能体）：

Agent 的核心在于 ReAct (Reason + Act) 模型。它不再是单纯的 $A \to B$，而是一个 Loop。

• 技术本质：它是 Model-driven 的。公式变为 $Action, Thought = LLM(Context, Goal, Tools)$。
• 工程挑战：
  • 非确定性：同样的输入，LLM 可能会给出不同的执行路径，这对习惯了单元测试（Unit Test）的 Java 工程师来说是巨大的挑战。
  • 幻觉控制：如果 Agent 误解了 Tool 的 API 定义（类似 Java 中的反射调用失败），会导致整个链路崩溃。
• Java 类比：它更像是带有自省（Introspection）能力和**策略模式（Strategy Pattern）**的动态对象，根据运行时环境自行决定调用哪个方法。

Agent主要是基于部分Agent范式，将决策规划的权力交给AI，让AI自己去规划。不让人去打断借入，所以他是流程不是那么确定的。优点是自助规划，更加智能。缺点是是不确定的，结果不够确定。

2.Function Calling 与 MCP 的对比

Function Calling：是模型的一种能力。模型根据描述判断需要调用哪个函数，并提取参数。它是 “模型寻找工具”。

• 技术本质：它是 Model 的原生能力。LLM 充当了“决策层”，它并不直接运行代码，而是输出一份符合特定 JSON Schema 的参数列表。
• Java 工程师的痛点：
  • 适配成本高：如果你要对接 OpenAI、Claude、Gemini，每个模型的 Tool 定义格式略有不同。
  • 紧耦合：业务逻辑（函数实现）通常与 AI 应用层混在一起。如果我有 100 个微服务提供的能力，AI 应用需要手写 100 个 ToolSpec。

MCP：是 Anthropic 推出的开放标准。它解决了“工具如何接入模型”的生态问题。以前每个 AI 都要对接不同的 API，现在通过 MCP，数据源（Google Drive、本地文件、数据库）可以标准地暴露给任何模型。它是 “工具接入模型的通用插头”。

MCP 的出现，标志着 AI 交互从“点对点定制”进入了**“标准化插件”**时代。它更像是一个 适配器模式（Adapter Pattern） 的大规模应用。

• 技术本质：它定义了一套 Client-Server 架构。
  • MCP Host：AI 应用（如 Claude Desktop, IDE）。
  • MCP Server：数据源或工具提供方（Google Drive, MySQL, GitHub）。
  • 传输协议：基于 JSON-RPC 的标准化通信。
• Java 工程师的视角：MCP 就是 AI 界的 JDBC。
  • 以前：每个数据库厂商都要写一套逻辑给应用调。
  • 现在：数据库厂商提供 JDBC Driver（MCP Server），应用层通过统一的 JDBC 接口（MCP Client）连接一切。

3.Multi-Agent

Multi-Agent System (MAS) 是指由多个能够自主决策的智能体（Agent）组成的集合，它们通过通信、协作、竞争或谈判来共同完成复杂的任务。

• 核心逻辑：将复杂问题拆解（Decomposition），由不同角色的 Agent 专项处理。
• 对比单 Agent：单 Agent 容易陷入“逻辑死循环”或“上下文爆炸”；Multi-Agent 则通过角色隔离，让每个 Agent 保持极高的专业度和较小的上下文窗口（Context Window）。

常见的范式：

A. 协作式 (Collaborative/Sequential)

Agent 们像流水线一样工作。

• 例子：Coder Agent 写代码 -> Reviewer Agent 找 Bug -> Tester Agent 写单测。
• Java 类比：责任链模式 (Chain of Responsibility)。

这种类似多个Agent协作，然后重点基本就是上一个Agent的output作为我们新的Agent的output。然后这个范式的重点是put的转移。

B. 代理/分发式 (Hub-and-Spoke / Manager-Worker)

存在一个 Leader/Orchestrator Agent，它负责理解需求、拆解任务并分发给 Worker。

• 例子：用户说“帮我做一个电商网站”，Manager 拆分给前端 Agent、后端 Agent、DB Agent。
• Java 类比：任务调度中心 (Job Scheduler)。

这个就是主子agent协作，然后我们的子Agent相当于一个大号的tools。然后这个范式的重点是上下文如何处理，隔离/不隔离。

C. 辩论/对弈式 (Debate/Peer-Review)

多个 Agent 针对同一个问题给出方案，相互质疑，最终总结出最优解。

• 优势：显著降低幻觉（Hallucination），提高逻辑准确性。

这个相当于swam范式，多个Agent进行互相讨论。然后这个的重点是最后我们如何处理多个Agent产生的内容，如果出现了冲突怎么解决。

4.Skills和MCP的区别

Skill (技能/插件) 像是“条件反射”或“专项手艺”：

• 它是为特定任务定制的。比如一个“查询天气”的 Skill，它包含了特定的 API 调用逻辑、参数校验以及如何把返回的 JSON 格式化给模型。
• 耦合度高：通常绑定在某个特定的框架（如早期 OpenAI Plugins 或自定义 Agent 框架）内。

MCP (Model Context Protocol) 像是“标准感知神经”或“通用接口”：

• 它是由 Anthropic 推出的开放标准。它不关心具体的业务逻辑，而是定义了模型如何连接到外部数据源（如 Google Drive、本地文件系统、数据库）。
• 解耦度高：一个 MCP Server 写好后，任何支持 MCP 协议的客户端（如 Claude、Cursor、IDE）都可以直接“插拔式”使用，无需重新编写集成代码。

Skill (自下而上)：开发者定义 sum(a, b)，模型只是调用者。这是一种功能驱动（Action-oriented）。

MCP (自上而下)：开发者定义一个 FileSystem Server，模型自己去发现里面有哪些文件、怎么读、怎么改。这是一种资源驱动（Resource-oriented）。

二者谁占用上下文窗口 (Context Window) 较大？

在初始化阶段，MCP 通常占用的上下文窗口更大。

为什么 MCP 消耗更多 Token？

1. 自描述开销 (Discovery Overhead)： MCP 为了实现“即插即用”，需要向模型发送大量的元数据 (Metadata)。当模型连接到一个 MCP Server 时，Server 会把所有的 Resources（可读取的文件、数据）、Tools（可执行的函数）及其详细的 JSON Schema 描述全部塞进 System Prompt。
2. Schema 的详尽性： 为了让模型在没有硬编码的情况下理解如何操作数据库或文件系统，MCP 的描述通常比简单的 Skill 函数定义要冗长得多。
3. 多轮交互的上下文堆积： MCP 鼓励模型频繁读取外部资源（Resources）。每一轮读取回来的原始数据都会作为 Context 持续堆积在对话历史中。

Skill 的优势（在 Token 节省方面）：

• 按需加载：开发者通常会对 Skill 进行精简，只在 Prompt 中描述核心功能，模型只有在触发特定的 Tool Call 时才会产生额外的 Token 消耗。
• 硬编码优化：很多逻辑（如参数预处理）在后端代码里就处理了，不需要在上下文里教模型“怎么做”。

比如：

Skill：可能只需要告诉模型 queryOrder(id)。

MCP：需要告诉模型 Database_Server 有哪些 Table，每个 Table 的 Schema 是什么，支持哪些 Prompt 模板。这些元数据在模型初始化连接（Sampling）时就会占据大量 KV Cache。

场景优化

1.重复问题

1.对于系统中大量重复或相似的用户问题，有哪些优化方式可以节约资源?若要实现该优化，具体如何拆解流程图，如何抽取共性问题并汇总答案?

看到这种问题，我们在工程上第一个想到的就是缓存？传统的缓存（如 Redis）是基于 Key 的精确匹配，但在 AI 场景下，用户问“如何重置密码？”和“密码忘了怎么找回？”虽然字面不同，但语义一致。

• 优化方案：引入**向量数据库（Vector DB）**作为语义缓存层。
• 收益：
  • 节约资源：命中缓存直接返回结果，Token 消耗降为 0（仅需极小的 Embedding 消耗）。
  • 降低延迟：从毫秒级的向量检索代替秒级的 LLM 生成。
  • 一致性：确保相似问题得到经过人工校验过的、高质量的标准答案。

然后我们的基本流程可能就是

首先用户进行输入->进行向量库的相似性匹配->然后是否召会的结果->没有就去再使用AI进行回复

但是这样还并不是完全的完善的，我们可以模仿Java的缓存系统也设计上多级缓存比如

• 精确缓存-使用HASH针对完成一样的重复问题
• 语义缓存-使用向量库针对完成相似的问题
• AI回复-使用AI进行恢复
• 兜底-静态的恢复，比如AI正在忙碌

但是那么我们这些共性的答案是从哪里去获得呢？肯定不是人一个一个去写的，需要自动化获取。

而这个就是我们知识库的一个搭建，这当然是最好的方式。

1. 问题提取：

算法选型：使用 HDBSCAN 或 K-Means 对历史日志中的 Query 向量进行聚类。

密度分析：识别出簇（Cluster）最大的部分，这些就是“共性问题”。

2. 共性询问提取：

对于每一个聚类簇，随机抽取 5-10 个代表性问题，发送给一个轻量级模型（如 GPT-4o-mini 或 Claude Haiku）：

“以下是用户问的 10 个相似问题，请总结出一个最标准、最通用的提问标题。”

3. 答案合成与精修

合成：将该簇下 LLM 之前的多个回答交给模型进行“合并同类项”，消除矛盾点，保留最全的逻辑。

人工校验 (Rerank/Human-in-the-loop)：资深工程师或运营对生成的“标准答案”进行最后审核，确保技术准确性。

索引固化：将该标准标题和答案存入 FAQ 库，并赋予极高的搜索权重。