Deep Agents
2026/9/16 9:16:56 网站建设 项目流程

代码学习参考:https://github.com/Bald0Wang/deepagents-in-action

官方教程参考:Deep Agents 实战 — 从零构建生产级 AI Agent 的完整指南

主要代码学习参照如上github地址,同时配套官方教程学习。

ch01-ch02

一、从 Framework 到 Harness

层次代表核心价值我的理解
底层 RuntimeLangGraph持久化、流式、人机协作、状态管理Agent 世界的"操作系统"
中层 FrameworkLangChain模型抽象、工具接口、Agent 循环、中间件在 LangGraph 之上包了一层,更易上手
上层 HarnessDeep Agents预置文件系统、任务规划、子 Agent、长期记忆直接给你一个装好的工具间

二、五分钟上手第一个Deep Agent

from langchain_openai import ChatOpenAI from deepagents import create_deep_agent model = ChatOpenAI( model=os.environ.get("MODEL_NAME", "deepseek-v4-flash"), api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com/v1", # 硅基流动则是 api.siliconflow.cn/v1 ) agent = create_deep_agent( model=model, tools=[get_weather], # 自定义工具 system_prompt="You are a helpful assistant.", ) result = agent.invoke({"messages": [{"role": "user", "content": "北京今天天气怎么样?"}]}) print(result["messages"][-1].content)

结构很清晰:注册模型;写工具函数;注册成工具;invoke

自定义工具的三要素:

参数类型标注:告诉Agent每个参数该传什么类型

Docstring: 告诉Agent这个工具的用途,何时调用

默认值:标记可选参数,减少必填,降低出错

三、基础环境配置

本项目基于linux系统,作为windows用户可以配置WSL来进行学习。具体详细配置步骤可以见本人另一篇帖子。

WSL(Windows Subsystem for Linux)是微软为 Windows 用户提供的一个子系统,它允许你在 Windows 上原生运行 Linux(不是虚拟机,不是双系统),直接使用 Bash、apt、gcc、Python、Node.js 等 Linux 工具。

安装/启动命令行:

wsl --install -d Ubuntu-24.04 //从网上下载并安装Ubuntu 从cmd进入Ubuntu命令: wsl -d Ubuntu-24.04 //启动并进入已安装好的Ubuntu

进入项目目录下激活虚拟环境:

source .venv/bin/activate

Vs Code打开当前linux项目(此时还在Ubuntu内 输入code .):

code .

排查网络相关问题时,可输入命令行查看代理配置:

env | gerp -i proxy

ch03虚拟文件系统

一、本章核心概念

1. 七个工具:把它们当作 CLI 的“文件操作语言”

工具

CLI 助手通常何时调用

关键实践

ls

用户说“看看项目有什么”

先理解目录,再决定检索范围

glob

找所有 Python、测试或 Markdown 文件

适合“按文件名/扩展名找”

grep

找 TODO、配置项、函数名、错误文本

适合“按内容找”;先文件级,再看命中行

read_file

阅读 README、报错日志、大文件

使用offset/limit分片,避免整文件进上下文

write_file

新建报告、迁移脚本、草稿文件

对产物写入目录做隔离

edit_file

精准改一处配置或文案

用完整旧字符串替换,匹配多处时应拒绝或显式全量替换

delete

删除 Agent 自己生成的临时文件

生产环境应纳入审批/审计

2. 五种常见后端,落到具体应用

后端

真实落点与生命周期

最适合的应用

不适合什么

CLI 示例

StateBackend

(默认)

LangGraph Agent State;同一线程可见,换线程丢失

学习、一次性任务、推理草稿

用户长期偏好、需要交付给人类的真实文件

生成本次排查计划和临时检索结果

FilesystemBackend

本地磁盘;写入会持久保存

本地编程助手、受控 CI 工作区、文档批处理

Web 服务直接暴露给外部用户

在仓库副本中改 README、生成报告

LocalShellBackend

本地磁盘 + 宿主机shell=True

个人开发机上可信的代码助手

生产环境、多用户系统、处理不可信输入

pytest -q

、格式化、Git 状态检查

StoreBackend

LangGraph Store;跨线程持久

用户偏好、长期知识、跨会话任务档案

临时大产物、需要真实项目文件的场景

记住“该用户习惯使用 pytest”

CompositeBackend

根据路径把数据路由到多个后端

真正的产品:临时工作区 + 长期记忆共存

只有一个简单生命周期的小脚本

/workspace/

临时,/memories/持久

二、核心代码理解

1. 01_builtin_file_tools.py(分为Part A 和 Part B

  • Part A:不用 LLM,直接测文件后端
    • 直接调用FilesystemBackend
    • 验证write / read / glob / grep / edit / delete
    • 结果确定,适合用assert做测试
    • 重点是确认“底层文件能力没问题”
  • 沙箱目录.sandbox
    • root_dir=SANDBOX指定真实文件只能写到.sandbox
    • virtual_mode=True/workspace/a.txt映射到.sandbox/workspace/a.txt
    • 作用是限制文件访问范围,避免误操作真实系统目录
  • 分片读取
    • read(offset=100, limit=50)表示跳过前 100 行,再读 50 行
    • 适合大文件,避免一次把整个文件放进上下文
  • glob 和 grep
    • glob:找文件路径,比如**/*.md
    • grep:找文件内容,比如搜索"TODO"
    • 常见思路:先找文件,再找内容,再局部读取
  • edit 后再验证
    • 先把一处TODO改成DONE
    • grep("TODO")
    • 从 3 处变 2 处,说明修改真的生效
  • Part B:让 Agent 自己调文件工具
    • 不再手写backend.write()backend.read()
    • 只给 Agent 自然语言任务
    • Agent 自己决定何时调用write_file / ls / read_file / grep / edit_file / delete
  • Part A 和 Part B 的区别
    • Part A:测“工具本身对不对”
    • Part B:测“LLM 会不会正确使用工具”
  • 最核心的测试思想
    • 先做无 LLM 的确定性测试
    • 再做有 LLM 的端到端测试
    • 这样出问题时更容易判断:是工具坏了,还是 Agent 调度错了

2. 02_context_auto_management.py

Deep Agent 的上下文并不是简单地不断把所有内容塞给 LLM,而是会通过“卸载”和“总结”两种机制主动控制 Context Window。

Part A:tool_token_limit_before_evict 低于工具输出 token 数时,
工具结果自动写入虚拟文件系统,对话历史只留「路径引用 + 前 10 行预览」。
Part B:SummarizationMiddleware 用 trigger={"messages": N} 低成本触发,
完整历史写入文件存档,对话历史替换为结构化摘要。

Part APart B
防什么单个 Tool Result 太大整个对话历史太长
MiddlewareFilesystemMiddlewareSummarizationMiddleware
触发条件tool_token_limit_before_evict=300trigger={"messages": 6}
被处理的内容工具返回结果老对话消息
原文去哪/large_tool_results/.../conversation_history/...
上下文里留下什么引用 + previewsummary + 最近上下文
最终目的减少超大工具结果占用 token防止长对话撑爆 context

3. 03_backends.py
覆盖课程五种后端:
- StateBackend : 临时存储(同线程内持久,换线程即丢)
- FilesystemBackend : 本地磁盘 + virtual_mode 路径沙箱
- LocalShellBackend : 文件工具 + execute(本地 Shell,无沙箱)
- StoreBackend : 跨线程持久化(namespace 按用户隔离)
- CompositeBackend : 混合路由(/memories/ -> Store,其余 -> State)

Backend数据真正放哪thread_id进程结束后特点
StateBackendAgent state❌ 看不到通常丢失临时工作区
FilesystemBackend本地磁盘✅ 文件还在✅ 还在真实文件系统
LocalShellBackend本地磁盘还能执行 Shell
StoreBackendLangGraph Store✅ 能看到取决于 Store 实现长期记忆、按 namespace 隔离
CompositeBackend按路径分流看路由看路由不同目录使用不同存储

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询