LangChain Agent、Tools 与 Memory

1. LangChain 在企业 AI 落地中的定位

如果说模型 API 是“发动机”，LangChain 更像是把发动机装进应用的开发框架。它提供模型统一接口、Agent 创建方式、工具封装、消息对象、记忆机制、中间件和调试观测能力。

视频中的主线很清晰：LangChain 不是只帮我们“调用大模型”，而是帮助研发团队影响模型行为、扩展模型能力，并把模型放进可测试、可调试、可集成的应用结构里。

官方文档中也强调，LangChain 的核心是 create_agent：它将 model + tools + prompt + middleware 组合成一个可配置的 Agent harness。LangChain agent 当前构建在 LangGraph 之上，因此天然能继承持久化、人机协同、可观测等底层能力。

2. Agent = Model + Harness

一个企业 Agent 不等于一个 LLM。LLM 只是大脑，Agent 还需要：

  • 模型接口：连接不同模型提供商。
  • 系统提示词：定义角色、边界、输出格式。
  • 工具：访问数据库、文件、API、搜索、业务系统。
  • 消息对象：组织系统消息、用户消息、模型消息、工具消息。
  • 记忆：保存会话上下文或用户偏好。
  • 中间件：在模型前后做摘要、过滤、审批、工具筛选。
  • 观测：追踪每一步调用、工具参数、成本和异常。

因此，企业落地时不要只讨论“选哪个模型”，更要讨论“模型外面那一圈工程结构是否可靠”。

3. 为什么 Agent 需要 Tools

视频里用“模型没有手脚”来解释工具，非常准确。LLM 的知识来自训练和上下文，如果不接工具，它不知道实时数据，也不能操作系统。

常见工具包括：

  • 查询当前时间。
  • 查询数据库。
  • 读取或搜索本地文件。
  • 调用业务 API。
  • 查询订单、库存、工单、客户信息。
  • 创建任务、发送消息、触发审批。
  • 执行受控代码或脚本。

工具的作用不是让 Agent “更像人”，而是让它能连接真实业务系统。没有工具的 Agent 主要是问答；有工具的 Agent 才可能进入业务闭环。

4. 工具设计的工程规范

在 LangChain 中，工具通常是带有名称、参数 Schema 和功能描述的函数。模型通过工具说明理解“什么时候用哪个工具、参数怎么填”。

企业研发团队要特别注意以下规范：

工具职责要小

不要设计一个 do_everything 工具。工具越大，模型越难选择，参数越难校验，审计越难做。

推荐：

get_order_status(order_id)
get_customer_profile(customer_id)
create_refund_request(order_id, reason)
search_policy_document(query)

不推荐：

handle_customer_issue(anything)

参数必须明确

工具参数要有类型、含义和边界。例如金额、日期、枚举值、ID 格式都应校验。

返回值必须结构化

不要让工具返回散乱文本。推荐返回 JSON-like 结构：

{
"status": "success",
"order_id": "O123",
"payment_status": "paid",
"shipment_status": "in_transit"
}

写操作要可审计

任何修改系统状态的工具都要记录：

  • 操作人或触发用户。
  • Agent run id。
  • 工具名称。
  • 参数。
  • 结果。
  • 审批记录。
  • 幂等键。

高风险工具要进入人工审批

例如删除文件、退款、转账、修改合同、发送外部消息等，不应让模型直接执行。

5. 模型统一接口：降低供应商切换成本

视频中提到可以通过统一模型接口接入 DeepSeek、GPT、Llama、Gemini 等不同模型。LangChain 的价值是把不同模型提供商的差异封装起来，让研发团队用相对一致的方式配置和调用模型。

模型配置通常关注：

  • model：模型名称或提供商前缀。
  • temperature：创造性和确定性平衡。
  • max_tokens：最大输出长度。
  • timeout：请求超时时间。
  • max_retries：重试次数。
  • API key：通常从环境变量读取。

企业内部建议增加一层模型网关或模型配置中心，而不是让每个 Agent 直接写死模型名称和密钥。这样可以统一做：

  • 成本控制。
  • 限流。
  • 灰度切换。
  • 多模型路由。
  • 审计。
  • fallback。

6. Messages：Prompt 不是一句话，而是一组上下文

视频里强调，Prompt 不是用户输入的单句文本，而是一个更大的消息集合。一个真实的 Agent 调用通常包含：

  • System message：角色、规则、安全边界。
  • Human message：用户输入。
  • AI message：模型历史回复。
  • Tool message：工具返回结果。
  • 历史摘要：长对话压缩后的上下文。

这点对研发团队非常关键。很多线上问题不是“模型不行”，而是消息上下文混乱：

  • 系统提示词和用户指令冲突。
  • 工具结果没有放回上下文。
  • 历史消息过长导致关键信息被稀释。
  • 删减消息时破坏了工具调用顺序。
  • 多轮对话没有 thread 隔离。

建议团队把消息组装逻辑当成核心代码，而不是临时字符串拼接。

7. Short-term Memory：短期记忆的本质

视频用多轮调用说明：所谓短期记忆，本质上是同一个会话线程中保留历史消息。模型每次看到之前的对话，所以看起来“记得”用户说过什么。

在 LangChain 中，短期记忆通常依赖 checkpointer 和 thread_id。同一个 thread_id 下的消息会被保存，后续调用可以继续访问。

短期记忆适合：

  • 多轮客服。
  • 任务执行上下文。
  • 表单补全。
  • 编程助手当前任务。
  • 同一次业务流程中的状态延续。

但短期记忆也有风险：

  • 历史越长，成本越高。
  • 旧信息可能干扰当前任务。
  • 上下文窗口有限。
  • 敏感信息可能在会话中残留。

因此需要消息管理策略：

  • trim：保留最近 N 条。
  • delete：删除无用或敏感消息。
  • summarize：把早期历史压缩成摘要。
  • filter：只保留与当前任务相关的信息。

8. Long-term Memory：让 Agent 记住跨会话信息

短期记忆解决“当前对话记住什么”，长期记忆解决“跨会话记住什么”。

长期记忆适合保存：

  • 用户偏好。
  • 常用配置。
  • 历史任务摘要。
  • 业务规则。
  • 个性化约束。
  • 组织级知识。

实现上通常需要：

  • embedding 模型。
  • 向量数据库或结构化存储。
  • memory store。
  • 写入策略。
  • 检索策略。
  • 更新和删除策略。

企业使用长期记忆时要非常谨慎。不是所有信息都应该长期保存，尤其是隐私、财务、医疗、合同、密钥等数据。建议引入数据分级：

  • 可记忆：公开偏好、低敏配置。
  • 需授权记忆：个人偏好、业务上下文。
  • 禁止记忆：密码、密钥、身份证、银行卡、敏感合同条款。

9. Middleware：把横切逻辑从 Agent 主流程中拿出来

视频后半部分讲到中间件，例如摘要中间件、工具筛选、模拟工具调用、人机回路等。对企业工程来说，中间件是非常重要的扩展点。

可沉淀的中间件包括：

  • Prompt 注入检测。
  • PII 脱敏。
  • 消息摘要。
  • Token 预算控制。
  • 工具白名单过滤。
  • 工具调用模拟。
  • 人工审批拦截。
  • 风险评分。
  • 输出合规检查。
  • 统一审计日志。

中间件的好处是让 Agent 业务代码保持清晰。不同业务 Agent 可以复用同一套安全、记忆、成本和观测能力。

10. LangSmith 与可视化调试

视频中展示了图形化调试界面和执行链路。对企业团队来说，可观测性不是可选项。

上线前必须能回答：

  • 这次请求用了哪个模型？
  • Prompt 里最终包含了哪些消息？
  • 模型为什么选择了这个工具？
  • 工具参数是什么？
  • 工具返回了什么？
  • 哪个中间件修改了消息？
  • 哪一步耗时最长？
  • 哪一步成本最高？
  • 出错后能否重放？

LangSmith 或同类平台的作用是把 Agent 从黑盒变成可审计系统。没有 trace 的 Agent 很难进入生产。

11. 企业研发团队的推荐架构

建议架构如下：

Frontend / API
-> Auth & Tenant Context
-> Agent Gateway
-> LangChain Agent
-> Model Adapter
-> Tool Registry
-> Memory Layer
-> Middleware Stack
-> Human Approval
-> Business Systems
-> Observability / Audit

关键模块说明：

  • Agent Gateway：统一入口，处理鉴权、限流、租户隔离。
  • Model Adapter：封装模型供应商差异。
  • Tool Registry：集中注册工具、参数 Schema、权限等级。
  • Memory Layer：区分短期会话记忆和长期用户记忆。
  • Middleware Stack：统一做安全、摘要、工具筛选、审批。
  • Observability：记录 trace、指标、错误和评估结果。

12. 从视频内容延伸出的研发实践

先读后写

第一批工具只做查询。等工具选择、参数校验、trace 和错误处理稳定后，再接写操作。

先人工确认，后逐步自动化

对写操作，先强制人工审批。上线一段时间后，根据命中率、错误率和风险等级逐步放开低风险场景。

先固定流程，后自主规划

不要一开始就让模型自由规划所有步骤。先用固定图或固定 Agent loop 包住关键路径，再逐步增加条件分支。

把 Prompt 当代码管理

Prompt 应版本化、可测试、可回滚。重要 Agent 的系统提示词应走评审流程。

建立评测集

每个 Agent 至少要有：

  • 正常问题集。
  • 边界问题集。
  • 恶意输入集。
  • 工具失败集。
  • 多轮记忆集。
  • 成本和延迟基线。

13. 常见误区

误区一：有了 Agent 就不需要业务规则

恰恰相反，Agent 更需要规则。模型负责理解和生成，业务规则负责边界和约束。

误区二：工具越多越好

工具越多，模型选择难度越高。要用工具筛选、工具分组和权限控制。

误区三：记忆越长越智能

过长的历史会增加成本，也会干扰模型。记忆要被管理，而不是无限累积。

误区四：Demo 能跑就能上线

生产 Agent 必须有 trace、权限、审批、回放、评测和告警。

14. 总结

LangChain 的价值在于把模型能力变成工程能力。它把模型、工具、消息、记忆、中间件和调试工具组织到一个可开发的框架里。

对公司研发团队而言，LangChain 的最佳落地方式不是快速堆一个“聊天机器人”，而是建设一套可复用的 Agent 工程底座：统一模型入口、统一工具注册、统一记忆策略、统一中间件、统一观测评估。

posted @ 2026-07-30 17:03  青柠_fisher  阅读(1)  评论(0)    收藏  举报