企业官网建设流程全解析

Agent方法论-Agent核心能力与开发框架

Agent 核心能力、开发框架与关键外围技术

核心结论：一个可落地的 Agent，不只是“接上大模型”。它需要同时具备规划、记忆、工具调用与执行能力，并依赖开发框架、模型服务、部署平台、评估系统和前端交互共同形成完整闭环。

一、Agent 开发技术栈全景

课程给出的 Agent 技术栈可以分成四层：

整体关系可以概括为：

用户目标 ↓ Planning（拆解与决策） ↓ Memory（读取上下文与历史经验） ↓ Tools（调用模型、检索、API、数据库等能力） ↓ Action（执行并获得环境反馈） ↓ 更新记忆 → 评估结果 → 继续规划或结束任务

二、Agent 的四项核心能力

1. Planning：规划

规划负责回答两个问题：当前目标应该如何拆解？下一步应该做什么？

课程将规划能力拆为两个层面：

• Prompt 层
  • 为 LLM 赋予合适的角色；
  • 提供充分上下文，例如从 Memory 中读取历史状态；
  • 使用思维链（Chain-of-Thought，CoT）等策略帮助模型组织推理过程。
• Agent 层
  • 根据目标、状态和工具反馈，动态决定下一步行动；
  • 必要时重新规划，而不是机械执行最初方案。

规划并不意味着步骤越多越好。生产环境通常还要限制最大迭代次数、总耗时和 Token 成本，避免 Agent 陷入无休止循环。

2. Memory：记忆

记忆用于维持任务连续性，并为后续决策提供上下文。

工程中需要同时关注记忆的写入条件、检索策略、压缩方式和淘汰机制。无限追加上下文会导致成本升高、响应变慢，并可能让真正重要的信息被噪声淹没。

3. Tools：工具

工具是 Agent 与外部世界交互的接口，常见形式包括：

• 搜索、RAG 与向量检索；
• 数据库查询与数据分析；
• 第三方 API 和企业内部服务；
• 文件读写、代码执行与自动化操作；
• 其他专业 Agent。

工具定义应至少包含：

工具名称 + 清晰描述 + 输入参数 Schema + 返回值结构 + 权限边界 + 超时策略 + 异常处理

工具描述越明确，模型越容易做出正确选择；多个工具功能重叠时，应通过边界说明和示例减少误调用。

4. Action：执行

Action 负责把模型的决策转化为真实操作，并将执行结果反馈给 Agent。完整闭环通常是：

生成行动 → 校验参数 → 调用工具 → 获取结果 → 更新状态/记忆 → 评估结果 → 决定继续或结束

生产系统中，执行层还要加入权限控制、幂等、重试、超时、审计和人工确认机制。尤其是写数据、发消息、付款等高风险操作，不能仅依赖模型的一次判断。

三、三类主流开发框架

1. LangChain / LangGraph

LangChain 是较完整的 LLM 应用开发框架，覆盖模型接入、Prompt、检索、工具、Agent、测试与部署等环节。

LangGraph 则更适合用图结构和状态机描述复杂工作流，例如课程展示的两个 Agent 协作流程：

START → Agent A → 路由判断 → Agent B / 工具节点 ↑ ↓ └──── 状态回传 ────┘ ↓ END

它的优势是流程、状态、条件分支和循环关系更明确，适合多 Agent、长流程以及需要中断恢复的任务。

2. LlamaIndex

LlamaIndex（早期名称为 GPT Index）定位为面向 LLM 应用的数据框架，重点能力包括：

• 数据连接器；
• 数据解析与结构化；
• 索引构建；
• 高级检索接口；
• 与外部应用框架集成。

它特别适合企业知识库、复杂 RAG，以及需要把多种私有数据源接入 Agent 的场景。

3. Semantic Kernel

Semantic Kernel 是 Microsoft 开源的 AI 应用开发框架，主要用于把 LLM 能力集成到现有软件系统中。

它强调插件化能力、流程编排和企业应用集成，适合 Microsoft / Azure 技术生态以及需要与既有业务代码深度结合的项目。

框架选型对比

框架只是工程加速器。选型时应优先考虑任务类型、数据形态、团队技术栈、部署环境和可观测性要求，而不是单纯比较功能数量。

四、生产部署与评估

1. Ollama：本地模型托管

Ollama 提供下载、运行和管理开源大模型的工具与服务，适合快速搭建本地或私有化模型服务。

典型价值：

• 降低本地运行模型的配置成本；
• 统一模型拉取、启动和管理方式；
• 数据不必离开本地环境；
• 便于开发阶段快速切换和验证不同模型。

2. LangServe：把 LangChain 应用发布成 API

LangServe 可以将 LangChain Runnable 快速部署为 REST API，并结合 FastAPI 与 Pydantic 提供服务路由和数据校验。

LangChain / LangGraph 应用 ↓ LangServe 封装为 REST API ↓ Web 前端 / 移动端 / 企业系统 / Python Client 调用

这样可以把 Agent 核心逻辑与具体客户端解耦，更利于测试、扩缩容和多端复用。

3. LangSmith：监控、调试与评估

复杂 Agent 的问题往往不是“有没有输出”，而是难以确认它为什么选错工具、在哪一步开始偏离，以及哪次检索带来了错误上下文。

LangSmith 主要用于：

• 记录模型、工具和链路调用轨迹；
• 可视化调试 Agent 的执行过程；
• 构建数据集并进行自动化评估；
• 对 RAG 的检索与回答质量进行评估；
• 比较不同模型、Prompt 和工作流版本。

它可以独立于 LangChain 使用。生产环境还应结合成功率、延迟、Token 成本、工具错误率和人工接管率等指标进行综合评估。

五、关键外围技术

1. Gradio：快速搭建演示界面

Gradio 适合用少量 Python 代码为模型或 Agent 构建交互界面，常见组件包括 Chatbot、文本处理、图像生成和数据展示。

适用场景：模型 Demo、内部验证、算法成果展示和快速收集反馈。

2. Streamlit：构建更完整的数据应用

当页面需要复杂布局、图表、表格、筛选器和状态交互时，可以使用 Streamlit。它适合数据分析 Agent、研究助手和内部运营工具。

3. Docker：统一运行环境

Docker 用于封装 Agent 应用及其依赖，解决不同环境之间的运行差异，并为后续部署提供统一交付物。

代码 + Python 依赖 + 系统依赖 + 配置约定 ↓ Docker Image ↓ 开发环境 / 测试环境 / 云服务器保持一致

需要注意：Docker 只解决环境封装问题，生产系统仍需考虑配置管理、密钥管理、日志、监控、资源限制和服务编排。

4. 云托管平台

云托管可以进一步提供持续部署、弹性扩缩容、域名和监控等能力。是否上云应结合数据合规、模型资源、访问规模和运维成本决定。

六、从原型到生产的推荐路径

1. 明确目标与成功指标 ↓ 2. 设计 Planning / Memory / Tools / Action ↓ 3. 用 LangChain、LlamaIndex 或 Semantic Kernel 构建原型 ↓ 4. 用 Gradio / Streamlit 完成交互验证 ↓ 5. 使用 Ollama 或云模型服务提供推理能力 ↓ 6. 通过 LangServe 等方式暴露 API ↓ 7. 使用 LangSmith 及业务指标持续评估 ↓ 8. Docker 化并部署到目标环境

七、工程落地检查清单

• 规划：是否定义最大步数、重规划条件和停止条件？
• 记忆：哪些信息进入短期记忆，哪些需要长期保存？
• 工具：输入输出是否结构化，异常和超时是否可恢复？
• 执行：高风险动作是否需要权限校验或人工确认？
• 框架：是否符合团队技术栈，能否支持调试和状态恢复？
• 模型服务：采用云端模型还是 Ollama 等私有化方案？
• 评估：是否同时评估正确率、完成率、延迟、成本和安全性？
• 交付：前端、API、容器和部署方式是否能够稳定协作？
• 可观测性：能否追踪一次任务中的模型调用、工具参数和路由决策？

总结

本节课程可以浓缩为下面这条工程链路：

Agent 产品 = 核心能力（Planning + Memory + Tools + Action）+ 开发框架 + 模型服务 + 评估平台 + 前端与部署体系

核心能力决定 Agent 能否完成任务；开发框架决定研发效率；模型托管和 API 服务决定系统能否运行；评估、前端、容器化与云平台则决定它能否真正交付并持续维护。