从 Prompt Engineering 到 Agent Engineering：一个成熟的 Agent 究竟需要什么？

一个成熟的 Agent，绝不仅仅是提示词工程（Prompt Engineering）。它更像是一套完整的软件系统，由 Workflow、Agent Runtime、Tools、MCP、Knowledge、Memory、Context Engineering 以及工程治理能力共同组成。

Prompt 只是入口，真正的核心是：如何让大模型具备理解业务、获取信息、调用工具、规划任务、执行流程和持续迭代的能力。

文章标签： AI Agent、Workflow、MCP、RAG、GraphRAG、Memory、Context Engineering、Multi-Agent

适合读者： Java / Python / TypeScript 开发者、AI 应用开发者、后端工程师、技术架构师。

---

一、重新认识 Agent：它不只是一个 Prompt

最近几年，Agent 这个概念越来越火。

很多技术文章介绍 Agent 时，往往从 System Prompt、角色设定、Few-shot 示例、提示词优化开始。

这些当然重要，但它们只是 Agent 工程中的一部分。

我们先考虑一个真实业务场景：

假设我们要开发一个电商订单分析 Agent，用户只需要输入：

帮我分析最近一个月的异常订单，找出可能存在退款风险的订单，并给出处理建议。

如果只是一个普通的大模型应用，它可能只能根据用户输入生成一段分析文字。

但它并不知道：

• 订单数据在哪里？
• 应该如何查询订单？
• 如何判断订单是否异常？
• 退款规则是什么？
• 是否有权限查看用户信息？
• 如果需要创建退款申请，应该调用哪个接口？
• 如何保证退款操作不会重复执行？
• 如果执行过程中出现异常，如何恢复？

这些问题都不是单纯优化 Prompt 就能解决的。

Prompt Engineering 解决的是如何让模型更好地理解和响应，而 Agent Engineering 解决的是如何让模型真正完成一个业务任务。

1.1 一个成熟 Agent 的整体架构

这张图表达的是一个重要观点：

Agent 并不是一个单独的模型调用，而是一个由多个工程模块协作完成任务的系统。

各模块的职责：

模块	核心职责
Prompt Engineering	告诉模型应该如何理解任务
Context Engineering	决定每次模型调用应该提供什么信息
Workflow	控制任务执行步骤与状态流转
Agent Decision	动态规划任务、选择工具
Tools	提供真实的业务执行能力
MCP	标准化连接外部能力
Knowledge	获取业务知识和外部信息
Memory	保存和复用历史信息
Guardrails	控制权限、安全和执行边界
Observability	监控执行过程
Evaluation	评估任务完成质量

需要注意：不是所有 Agent 都必须具备上述所有模块。

架构设计应该围绕业务需求，而不是为了堆砌技术而堆砌技术。

---

二、Workflow：让 Agent 的执行过程可控

Workflow 是从简单 AI 助手走向成熟 Agent 的重要一步。

我们可以先看一个最简单的 Agent 执行过程：

这种方式很灵活，但是如果把所有执行逻辑都交给模型自由决定，就会产生一些问题：

• 执行步骤不稳定。
• 重要业务节点可能被跳过。
• 任务失败后难以恢复。
• 执行过程难以审计。
• 高风险操作缺少明确控制。
• 复杂任务容易出现重复调用和循环调用。

这时候就需要 Workflow。

2.1 Workflow 和 Agent 的区别

可以简单理解为：

Workflow： 开发者提前设计执行路径，程序控制任务按照什么顺序执行。

Agent： 模型根据目标、上下文和执行结果，动态决定下一步做什么。

二者并不是互斥关系。

成熟的系统通常采用：

• 确定性任务交给 Workflow。
• 需要理解、分析、判断的任务交给 Agent。
• 需要操作业务系统的任务交给 Tools。
• 高风险操作通过审批节点控制。

2.2 Workflow + Agent 的协作流程

假设我们开发一个订单异常分析系统。

在这个流程中：

步骤	实现方式	原因
参数解析	LLM / 规则	理解用户自然语言
订单查询	Tool	获取真实业务数据
数据校验	程序代码	确定性规则
异常识别	规则 + Agent	规则筛选与语义判断结合
风险分析	Agent	需要理解和推理
退款审批	Workflow	必须有明确业务控制
退款申请	Tool	调用真实业务接口
结果输出	LLM	整理和解释结果

这才是一个比较合理的 Agent 工程化设计。

2.3 常见 Workflow 框架

技术	特点	适用场景
LangGraph	State、Node、Edge、Checkpoint	有状态、复杂分支的 Agent
Temporal	持久化工作流、重试、长任务执行	企业级长流程
Dify Workflow	可视化工作流	快速搭建 AI 业务应用
自定义 State Machine	自己管理状态与转换	复杂业务状态机
原生代码编排	简单、灵活、可控	流程较简单的场景

我的建议是：

不要一开始就引入复杂的工作流框架。

如果只是几个 Tool 的顺序调用，原生代码就可以实现。

当出现复杂分支、任务恢复、人工审批、长时间运行和多节点状态管理时，再考虑 LangGraph 或 Temporal。

---

三、Tools：让模型真正具备执行能力

如果说 Prompt 是 Agent 的大脑，那么 Tools 就是 Agent 与外部世界交互的手。

模型本身并不能直接访问我们的业务数据库，也不应该拥有无限制的业务系统操作权限。

我们需要把业务能力封装成一个个独立的 Tool。

3.1 自定义 Tool 的基本设计

例如，一个订单系统可以提供以下工具：

3.2 Python 自定义 Tool 示例

这里使用 Python 演示，实际项目可以根据自己的业务系统进行封装。

from typing import Any


def query_order(order_id: str) -> dict[str, Any]:
    """
    根据订单编号查询订单详情。
    """
    return order_service.get_order(order_id)


def query_order_statistics(
    start_date: str,
    end_date: str
) -> dict[str, Any]:
    """
    查询指定时间范围的订单统计数据。
    """
    return order_service.statistics(
        start_date,
        end_date
    )


def check_refund_policy(
    order_id: str
) -> dict[str, Any]:
    """
    检查订单是否符合退款条件。
    """
    return refund_service.check_policy(order_id)

模型需要知道工具的名称、用途和参数结构。

例如：

{
  "name": "query_order",
  "description": "根据订单编号查询订单详情",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "需要查询的订单编号"
      }
    },
    "required": ["order_id"]
  }
}

3.3 Tool 的完整调用链路

这里有一个非常重要的设计原则：

模型只负责提出调用意图，真正的业务校验和执行必须由程序完成。

生产级 Tool 需要考虑：

1. 参数校验。
2. 用户身份验证。
3. 数据权限控制。
4. 超时和重试。
5. 幂等性。
6. 错误处理。
7. 调用日志。
8. Trace 追踪。
9. 返回结构规范化。

尤其是退款、支付、删除等具有副作用的操作，不能因为模型生成了一个 Tool Call 就直接执行。

---

四、MCP：标准化连接外部能力

当系统只有几个 Tool 时，可以直接在应用内部注册函数。

但是当业务越来越复杂时：

• 订单系统有自己的 Tool。
• 用户系统有自己的 Tool。
• 商品系统有自己的 Tool。
• CRM 系统有自己的 Tool。
• 文档系统有自己的 Tool。
• 第三方服务也有自己的 Tool。

如果每一个 Agent 都单独维护这些集成代码，就会出现大量重复开发。

这时候可以考虑 MCP。

MCP 全称 Model Context Protocol，是一种用于 AI 应用连接外部工具和上下文的开放协议。

4.1 MCP 能提供什么？

MCP 主要有三类核心能力：

能力	作用	示例
Tools	执行操作	查询订单、创建退款申请
Resources	提供上下文资源	数据库结构、业务文档
Prompts	提供可复用提示模板	订单分析模板

可以简单理解为：

Tool 解决的是具体能力问题，MCP 解决的是如何标准化发现和接入这些能力的问题。

4.2 MCP 整体架构

每个 MCP Server 可以独立部署，也可以根据实际规模部署在同一个服务中。

例如：

Order MCP Server 可以暴露：

order.get_detail
order.list
order.statistics
order.check_status
order.get_refund_policy
order.create_refund

Agent 只需要通过 MCP Client 连接对应服务，就可以发现并调用这些能力。

4.3 MCP 和普通 Tool 的区别

对比维度	普通 Tool	MCP
本质	一个具体的可调用能力	标准化连接协议
实现方式	函数、SDK、API	MCP Client / Server
能力发现	通常由应用自行注册	支持协议层能力发现
跨应用复用	需要自行维护集成	更适合标准化复用
部署方式	通常与应用绑定	可以独立部署
是否必须	否	否

并不是所有 Tool 都需要包装成 MCP。

内部简单的函数可以直接作为 Tool。

需要被多个 Agent、多个应用复用的能力，可以考虑独立 MCP Server。

4.4 自定义 MCP Server 示例

以 Python 为例，使用 MCP Python SDK 可以快速创建一个 Server。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Order MCP")


@mcp.tool()
def query_order(order_id: str) -> dict:
    """根据订单编号查询订单详情。"""
    return order_service.get_order(order_id)


@mcp.tool()
def query_order_statistics(
    start_date: str,
    end_date: str
) -> dict:
    """查询指定时间范围的订单统计。"""
    return order_service.statistics(
        start_date,
        end_date
    )


if __name__ == "__main__":
    mcp.run()

这只是一个简化示例，真实部署时还需要配置传输方式、鉴权、权限边界和异常处理。

---

五、RAG 之外，还有哪些更合适的知识获取方案？

这是我觉得 Agent 开发中非常值得深入研究的一个方向。

现在很多 Agent 教程只要涉及知识库，就会直接推荐：

RAG + Embedding + Vector Database。

但实际业务中，并不是所有知识都适合使用向量检索。

RAG 很重要，但它不是所有问题的标准答案。

5.1 传统 RAG 的基本流程

先看一下经典向量 RAG 的流程。

传统 RAG 解决了大模型无法直接获取私有知识的问题。

但在实际使用中，也会遇到一些局限。

5.2 为什么不能所有知识都使用 RAG？

举几个真实业务场景。

场景一：查询订单状态

用户问：

订单 ORD10001 当前是什么状态？

如果订单状态在 MySQL 中，直接调用订单查询 API 就可以了。

完全没有必要先把订单数据向量化，再进行相似度检索。

场景二：查询公司退款制度

用户问：

公司规定什么情况下可以申请退款？

这类非结构化文档，可以使用全文检索、向量 RAG 或混合检索。

场景三：分析复杂业务关系

用户问：

为什么用户 A 的订单退款失败？这个商品是否还有其他类似问题？

这可能涉及用户、订单、商品、店铺、退款记录等多个实体之间的关系。

单纯使用向量相似度检索不一定能很好地解决。

这时候就可以考虑 Knowledge Graph 或 GraphRAG。

5.3 知识获取方案全景图

下面分别介绍这些方案。

5.4 方案一：SQL / Business API

适合：

• 订单数据。
• 用户信息。
• 商品信息。
• 库存数据。
• 交易流水。
• 统计分析。

例如：

SELECT
    status,
    COUNT(*) AS total
FROM orders
WHERE created_at >= '2026-10-01'
GROUP BY status;

优势：

• 数据准确。
• 查询结果可追溯。
• 实时性较好。
• 适合结构化数据。
• 不需要额外向量化。

注意：不建议直接把任意 SQL 执行权限交给模型。更合理的方式是通过只读视图、受限查询 Tool、SQL 校验和数据权限控制来实现。

5.5 方案二：BM25 / 全文检索

适合：

• 产品名称。
• 文档标题。
• 订单编号。
• 关键词。
• 精确短语。
• 大规模文本检索。

常见技术：

• Elasticsearch
• OpenSearch
• Apache Lucene
• BM25

例如用户搜索：

星盟订单退款规则

如果文档中就包含这几个关键词，全文检索通常可以快速找到相关文档。

它与向量检索最大的区别在于：

全文检索更关注关键词匹配，向量检索更关注语义相似度。

5.6 方案三：Hybrid Search 混合检索

Hybrid Search 是一个非常实用的方向。

它同时使用：

• BM25 关键词检索。
• Vector 向量检索。

然后将两路候选结果进行融合，再进行重排。

例如用户问：

订单退款失败的原因有哪些？

BM25 可能找到包含“退款失败”的文档。

Vector Search 可能找到包含“退款审核未通过”“退款申请异常”的文档。

两者结合，通常比单纯依赖一种检索方式更全面。

5.7 方案四：Knowledge Graph / GraphRAG

传统 RAG 更关注文本片段之间的语义相似度。

知识图谱则更关注实体与实体之间的关系。

例如：

当用户询问复杂关系时，系统可以沿着实体关系进行查询。

例如：

商品 P 是否存在集中退款问题？

系统可能需要：

1. 查询商品 P。
2. 查询购买商品 P 的订单。
3. 查询这些订单的退款记录。
4. 查询相关投诉记录。
5. 分析退款失败原因。
6. 结合业务规则生成结论。

这类任务更适合结构化关系查询与图检索协同完成。

值得关注的项目：

项目	方向
Microsoft GraphRAG	图结构增强的检索与全局分析
LightRAG	轻量知识图谱与 RAG
Neo4j GraphRAG	基于图数据库的检索增强生成
Graphiti	面向时间变化信息的知识图谱与记忆

相关地址：

• https://github.com/microsoft/graphrag
• https://github.com/HKUDS/LightRAG
• https://neo4j.com/developer/genai-ecosystem/graphrag/
• https://github.com/getzep/graphiti

需要注意：GraphRAG 并不是传统 RAG 的完全替代品。

它在复杂关系、多文档关联和全局主题分析方面有优势，但也会带来实体抽取、图构建、数据更新和维护成本。

5.8 方案五：Long Context

有时候最简单的方案反而更有效。

如果知识规模比较小，文档数量有限，而且上下文完整性很重要，可以直接将完整文档放入模型上下文。

例如：

• 一份业务规范。
• 一份技术设计文档。
• 一份项目配置文件。
• 一段完整代码。
• 少量关联文档。

这种情况下，可能根本不需要先做 Chunk、Embedding 和 Vector Database。

但 Long Context 并不是无限制的。

需要考虑：

• Token 成本。
• 上下文窗口限制。
• 模型对长文本的利用能力。
• 响应延迟。
• 信息冗余。

5.9 方案六：Agentic Retrieval

传统 RAG 往往是：

用户提问 → 检索一次 → 生成答案。

但复杂问题可能需要多次检索。

这就引出了 Agentic Retrieval。

它的核心是：

让 Agent 根据当前问题和已经获取的证据，动态决定下一步检索什么。

例如：

用户问：

分析最近一个月退款率最高的商品，并找出这些商品退款率高的原因。

Agent 可以：

1. 先通过 SQL 查询退款率排名。
2. 找出 Top 10 商品。
3. 查询商品相关投诉记录。
4. 使用全文检索查询售后反馈。
5. 对关联文档进行语义检索。
6. 分析证据是否充分。
7. 如果不充分，继续补充查询。
8. 最终生成分析报告。

这比固定执行一次向量检索更加灵活。

不过需要给 Agent 设置最大检索轮数、超时、Token 预算和停止条件，防止无限检索。

5.10 知识方案怎么选？

场景	推荐方案
订单、用户、商品等结构化数据	SQL / API
关键词、编号、标题搜索	BM25
自然语言文档问答	Vector RAG
关键词与语义结合	Hybrid Search
多实体、多层级关联	Knowledge Graph
多文档全局主题分析	GraphRAG
小规模完整文档	Long Context
复杂多步骤信息查询	Agentic Retrieval

我的理解是：

RAG 不需要被淘汰，而是应该从唯一的知识获取方案，变成整个 Knowledge System 中的一个可选组件。

---

六、Memory：上下文不等于记忆

另一个经常被混淆的概念就是 Memory。

很多简单 Agent 会把历史聊天记录不断追加到 Prompt 中，并称之为记忆。

但实际上，历史消息只是上下文的一部分。

Context 和 Memory 有区别：

• Context：当前任务需要使用的信息。
• Memory：系统希望跨任务、跨会话保留并复用的信息。

例如：

用户第一次说：

以后查询订单时，优先按照创建时间倒序排列。

如果系统将这个偏好保存下来，那么下一次用户查询订单时，就可以自动使用这个偏好。

6.1 Memory 的常见分类

类型	说明	示例
Short-term Memory	短期记忆	当前任务执行状态
Long-term Memory	长期记忆	用户长期偏好
Episodic Memory	情节记忆	历史任务执行记录
Semantic Memory	语义记忆	已整理的事实和知识

6.2 Memory 的工作流程

一个好的 Memory 系统还需要考虑：

1. 什么信息值得保存？
2. 什么信息不应该保存？
3. 新旧信息冲突怎么办？
4. 如何更新已有记忆？
5. 记忆什么时候过期？
6. 如何删除和管理记忆？
7. 不同用户之间如何隔离？

不要简单地把所有历史对话存起来，然后每次全部塞进 Prompt。

真正的 Memory 应该具有筛选、归纳、更新和生命周期管理能力。

---

七、Plugin / Connector：连接外部生态

除了 Tool 和 MCP，还有一个经常出现的概念：Plugin / Connector。

它们通常用于将 Agent 与外部应用和服务连接起来。

例如：

• GitHub：代码仓库、Issue、Pull Request。
• Slack：消息和团队协作。
• Google Drive：文件和文档。
• Gmail：邮件。
• 数据库 Connector：业务数据。
• 搜索 Connector：互联网信息。

可以简单理解：

技术	主要职责
Tool	定义一个具体可执行的能力
MCP	标准化能力和上下文的连接协议
Plugin / Connector	提供面向外部服务的集成能力

它们之间并不冲突。

一个 Connector 内部可以封装 API、Tool 或 MCP Server。

一个 Agent 也可以同时使用原生 Tool、MCP 和其他集成方式。

例如：

需要注意：连接外部服务不等于可以无条件执行所有操作。

例如发送邮件、修改代码、合并 PR、资金操作等，都需要明确的权限和审批控制。

---

八、Java、Python、TypeScript：Agent 应该用什么语言？

很多人在开发 Agent 时会纠结一个问题：

到底应该选择 Java、Python 还是 TypeScript？

我的观点是：

Agent 是一种系统架构，而不是某种编程语言的专属能力。

Java、Python、TypeScript 都可以构建成熟的 Agent 系统。

只不过它们各自的生态和优势不同。

8.1 Python：AI 生态丰富

Python 在 AI 领域拥有非常成熟的生态。

值得关注的项目：

技术	作用
LangGraph	Agent 编排与状态管理
LlamaIndex	数据接入与知识检索
Haystack	搜索与 RAG Pipeline
Transformers	模型加载与推理
PyTorch	深度学习框架
FastAPI	API 服务
MCP Python SDK	MCP Server / Client

Python 比较适合：

• Agent 核心逻辑。
• RAG 与检索系统。
• Embedding。
• 模型实验。
• 数据处理。
• AI 算法集成。
• 知识图谱处理。

Python 最大的优势是生态丰富，尤其是新兴 AI 项目，很多都会优先提供 Python 实现。

8.2 Java：企业业务集成能力强

Java 并不是不能开发 Agent。

事实上，如果原有系统已经采用 Spring Boot 架构，那么直接使用 Java 开发 Agent 服务也是非常合理的选择。

值得关注：

技术	作用
Spring AI	Spring 生态下的 AI 集成
LangChain4j	Java LLM 应用开发框架
MCP Java SDK	Java MCP 实现
Spring Boot	企业级服务开发

Java 的优势：

• 成熟的企业级开发生态。
• 与现有微服务集成方便。
• 事务和权限管理成熟。
• 适合复杂业务系统。
• 方便复用已有业务代码。

如果你的 Agent 主要围绕订单、支付、商品、库存、用户等业务系统运行，Java 完全可以承担核心业务服务。

8.3 TypeScript：适合 AI 应用与全栈开发

TypeScript 在 AI 应用层也有非常好的发展。

值得关注：

技术	作用
Vercel AI SDK	AI 应用与流式交互
LangGraph.js	JavaScript Agent 编排
Mastra	TypeScript Agent 框架
MCP TypeScript SDK	MCP 开发

适合：

• Web AI 应用。
• 前后端一体化开发。
• 流式响应。
• 工具调用。
• WebSocket。
• AI 产品快速迭代。

8.4 三种语言的技术选型对比

维度	Python	Java	TypeScript
AI 生态	非常丰富	持续发展	丰富
数据处理	优势明显	成熟	适合应用层
企业业务	可以实现	非常成熟	可以实现
模型集成	丰富	丰富	丰富
MCP 支持	有 SDK	有 SDK	有 SDK
Web 集成	可以实现	可以实现	非常方便
科学计算	优势明显	相对有限	相对有限

8.5 多语言协作架构

一个企业级系统完全可以使用多语言协作。

例如：

• TypeScript：前端交互、流式响应、AI Gateway。
• Python：Agent 编排、模型调用、检索和数据处理。
• Java：业务规则、事务、权限和原有微服务。
• MCP：不同能力之间的标准化连接。

但需要注意：

多语言不是必须的。

如果团队规模较小、业务简单，先用一种语言实现完整闭环，通常比一开始就拆成三个微服务更加合理。

语言选择应该由团队技术栈、生态成熟度、部署成本和业务边界决定。

---

九、生产级 Agent 还需要哪些工程保障？

一个 Agent 能在 Demo 中运行，不代表它能在生产环境稳定工作。

真正的生产级 Agent，还需要考虑以下问题。

9.1 Context Engineering：上下文工程

Prompt Engineering 主要关注提示词怎么写。

Context Engineering 则更加关注：

每次模型调用时，究竟应该给模型提供哪些信息？

一个合理的上下文可能由以下部分组成：

并不是所有信息都应该放进 Prompt。

上下文需要经过：

• 信息筛选。
• Token 预算控制。
• 历史消息压缩。
• 相关性排序。
• 敏感信息过滤。
• 冗余信息清理。

这也是为什么 Context Engineering 正在成为 Agent 工程中的重要方向。

9.2 Guardrails：安全与权限控制

Agent 可能会调用真实业务系统，因此权限控制尤其重要。

操作	推荐策略
查询订单	用户身份和数据范围校验
查询用户信息	敏感字段脱敏
查询商品	业务权限校验
生成退款建议	业务规则校验
创建退款申请	人工确认或审批
实际退款	服务端权限、金额校验、幂等控制
删除数据	高风险审批

安全不能只依赖 Prompt。

真正的权限控制必须在 Tool Runtime、业务服务和数据访问层实现。

9.3 Observability：可观测性

传统 Web 应用可以通过接口日志定位问题。

但 Agent 的执行链路通常更加复杂。

例如：

我们应该能够追踪：

• 用户请求。
• 模型调用。
• Token 消耗。
• Tool 选择。
• Tool 参数。
• MCP 请求。
• 检索结果。
• Workflow 状态变化。
• 每个节点执行耗时。
• 错误和重试记录。

值得关注：

• LangSmith
• OpenTelemetry
• Arize Phoenix

9.4 Evaluation：Agent 评估体系

Agent 不能只通过“感觉回答得不错”来评估。

需要建立更加系统的评估指标。

指标	说明
Task Success Rate	任务是否真正完成
Tool Selection Accuracy	是否选择正确工具
Parameter Accuracy	工具参数是否准确
Retrieval Recall	是否检索到需要的信息
Answer Groundedness	答案是否有事实依据
Execution Latency	整体执行耗时
Cost per Task	每个任务的 Token 和工具成本
Safety Violation Rate	是否出现越权或违规操作

最好建立固定测试集，每次修改 Prompt、模型、Workflow 或 Tool 后，都进行回归测试。

---

十、一套真正可落地的企业级 Agent 架构

前面介绍了很多模块，最后我们把它们整合起来。

这套架构可以拆分成五个核心部分：

层级	负责什么
智能决策层	理解问题、规划任务、选择工具
流程编排层	控制任务执行顺序和状态
能力接入层	连接内部业务和外部系统
知识与记忆层	提供实时数据、知识和历史信息
工程治理层	保证安全性、稳定性和可观测性

10.1 从零开始应该怎么建设？

不建议一开始就引入 Multi-Agent、复杂 GraphRAG、几十个 MCP Server。

可以按照以下阶段推进。

阶段	建设内容	目标
第一阶段	LLM + Prompt + Tools	完成真实业务任务
第二阶段	Workflow + State	让执行过程可控
第三阶段	自定义 MCP	标准化复用业务能力
第四阶段	Knowledge + Retrieval	解决业务知识获取
第五阶段	Memory + Context	支持跨任务信息管理
第六阶段	Guardrails + Observability	提升生产可靠性
第七阶段	Multi-Agent	处理真正需要多角色协作的任务

---

十一、值得关注的技术项目与生态

最后整理一份 Agent 工程相关的技术清单，方便后续深入研究。

技术方向	项目	官方地址
Agent 编排	LangGraph	https://www.langchain.com/langgraph
Agent 框架	OpenAI Agents SDK	https://openai.github.io/openai-agents-python/
知识接入	LlamaIndex	https://www.llamaindex.ai/
RAG Pipeline	Haystack	https://haystack.deepset.ai/
图检索	Microsoft GraphRAG	https://github.com/microsoft/graphrag
轻量图检索	LightRAG	https://github.com/HKUDS/LightRAG
MCP 协议	Model Context Protocol	https://modelcontextprotocol.io/
Python MCP	MCP Python SDK	https://github.com/modelcontextprotocol/python-sdk
Java MCP	MCP Java SDK	https://github.com/modelcontextprotocol/java-sdk
TypeScript MCP	MCP TypeScript SDK	https://github.com/modelcontextprotocol/typescript-sdk
Java AI	Spring AI	https://spring.io/projects/spring-ai
Java AI	LangChain4j	https://docs.langchain4j.dev/
TypeScript AI	Vercel AI SDK	https://sdk.vercel.ai/
工作流	Temporal	https://temporal.io/
可观测性	LangSmith	https://www.langchain.com/langsmith
可观测性	Arize Phoenix	https://phoenix.arize.com/

---

十二、总结：从 Prompt Engineering 走向 Agent Engineering

我一直觉得，Agent 这个方向最值得研究的地方，并不是如何把模型调教得更像一个人，而是如何让模型真正成为一个能够使用工具、理解业务、管理状态并完成任务的系统。

Prompt Engineering 依然重要，但它不应该成为 Agent 开发的全部。

我们需要理解：

• Workflow 让任务执行更加可靠。
• Tools 让模型具备实际操作能力。
• MCP 让外部能力可以标准化接入和复用。
• RAG / GraphRAG / SQL / Hybrid Search 解决不同类型的知识获取问题。
• Memory 让 Agent 能够保存和利用长期信息。
• Context Engineering 让模型在正确的时机获得正确的信息。
• Plugin / Connector 扩展外部系统的集成能力。
• Guardrails 保证系统执行操作时的安全性。
• Observability / Evaluation 让 Agent 具备生产环境所需要的可观测性和持续优化能力。

一个成熟的 Agent，真正的竞争力不是模型有多聪明，而是整个系统能否可靠地完成真实世界中的复杂任务。

模型决定能力上限，工程决定能力能否真正落地。

这就是我理解的：

从 Prompt Engineering 走向 Agent Engineering。

---

参考资料

1. Anthropic - Building Effective Agents：https://www.anthropic.com/research/building-effective-agents
2. Model Context Protocol：https://modelcontextprotocol.io/
3. LangGraph：https://langchain-ai.github.io/langgraph/
4. Microsoft GraphRAG：https://github.com/microsoft/graphrag
5. OpenAI Agents SDK：https://openai.github.io/openai-agents-python/
6. Spring AI：https://spring.io/projects/spring-ai
7. Temporal：https://docs.temporal.io/
8. LlamaIndex：https://www.llamaindex.ai/

注：Agent 生态发展较快，相关框架、SDK 和 API 可能发生变化，正式落地时请以各项目当前官方文档和版本说明为准。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/z001126/article/details/170450151