LangChain DeepAgents 速通指南（十二）——一文详解生产级智能体的命令体系和工程设计

前言

上篇文章拆解了 DeepAgents Code 的状态与记忆管理体系。大家先简单回顾一下：状态依赖 LangGraph 的检查点机制，确保会话能在中断后无缝恢复；记忆则走分层长期存储路线，通过 AGENTS.md、MemoryMiddleware 做精准注入，再用防护中间件锁住关键区域，既实现了跨会话的知识沉淀，也把安全隔离做到了位。整套设计背后，是 LangChain 团队对生产级智能体在可靠性、安全性和可扩展性三个维度上的考量。

本篇笔者将把视线转向另一个核心模块------命令体系 。如果大家用过 Claude Code、OpenCode 这类终端智能体，一定对 / + 指令 的交互方式不陌生：压缩上下文、跳转命令行、切换模式，一条斜杠命令下去，智能体立刻响应。对终端智能体而言，命令就是用户与系统之间最直接的语言------用户用命令表达意图，智能体用命令快速执行动作，设计顺手与否几乎决定了用户的使用意愿。DeepAgents Code 沿用了类似Claude Code等智能体的命令设计思路，共注册分发了 28 个斜杠命令，但命令体系远不止列清单那么简单：优先级如何裁决？参数解析遇到特殊字符怎么处理？启动时要不要自动检查更新、检测运行环境？这些看似琐碎的细节恰恰构成了从"能用"到"好用"的落差，笔者今天就和大家一起深入DeepAgents Code的命令体系，看看DeepAgents Code是如何设计出"交互效率"和"系统安全"兼顾的命令系统。

一、DeepAgents Code 命令体系

正式拆解细节之前，笔者先带大家在宏观上把 DeepAgents Code 的命令体系摸清楚。它并不是一个简单的 if-else 分发逻辑，而是一套覆盖了命令注册、优先级裁定、分发路由和具体执行的完整工程框架。

下图展示了从命令定义到执行完成的完整链路，整个体系按职责拆成了五层：

1. 命令来源层：三类源头------静态内置命令、动态技能命令、启动时注入的命令。
2. 命令注册层：将上述三种来源统一抽象为标准的命令类，屏蔽差异，便于后续统一处理。
3. 优先级层：划分五个优先级等级，决定哪些命令可以插队、哪些必须排队。
4. 命令分发层：依据优先级裁决结果，将命令路由到对应的执行路径。
5. 命令处理层：每个命令的具体业务逻辑落地。

有了这个整体框架做底子，下面笔者将一层一层拆开看：每一层解决什么问题、怎么设计的，最后再串一个完整实例，把整个执行流程走通。

二、DeepAgents Code 命令体系部件详细介绍

2.1 命令来源与命令注册

2.1.1 斜杠命令来源

斜杠命令（Slash Commands）是 DeepAgents Code 最核心的交互方式。大家在输入框里敲 /help、/model、/quit，智能体立刻响应。这些命令的定义都集中在 command_registry.py 的 COMMANDS 元组中，它也是所有斜杠命令的唯一数据源：

COMMANDS: tuple[SlashCommand, ...] = (
    SlashCommand(
        name="/agents",
        description="Browse and switch between available agents",
        bypass_tier=BypassTier.IMMEDIATE_UI,
        hidden_keywords="switch profile persona",
    ),
    SlashCommand(
        name="/auth",
        description="Connect and manage provider and service credentials",
        bypass_tier=BypassTier.IMMEDIATE_UI,
        hidden_keywords="key keys credential credentials login token api tracing langsmith",
        aliases=("/connect",),
    ),

每个 SlashCommand 对象包含以下几个关键字段：

字段	说明
name	命令名称（如 /help）
description	命令描述（用于自动补全和help屏幕）
bypass_tier	优先级（决定命令是否可以"插队"）
hidden_keywords	隐藏关键词
aliases	别名（如 /quit 的别名是 /q）

其中 hidden_keywords 的设计很巧妙：它不会出现在自动补全列表里，但用户输入相关词时能模糊匹配到对应命令。比如 /auth 的 hidden_keywords 包含了 "token api"，用户敲 /token 也能命中 /auth，省去了记精确命令名的负担。

有了 COMMANDS 这个单一数据源，自动补全列表、优先级集合等都由它派生而来，避免多处维护导致不一致。在 command_registry.py 底部可以看到生成自动补全列表的逻辑：

class CommandEntry(NamedTuple):
    """A single autocomplete entry for the slash-command controller."""
    name: str
    description: str
    hidden_keywords: str
    argument_hint: str

SLASH_COMMANDS: list[CommandEntry] = [cmd.to_entry() for cmd in COMMANDS]

SLASH_COMMANDS 直接供给 Textual 的自动补全控制器，用户输入 / 时，匹配列表就来自这里。

2.1.2 技能命令：动态扩展

Skill 是目前智能体扩展能力的核心手段------通过加载不同 Skill，智能体能具备各种各样功能。（对 Skill 不熟悉的读者可以参考：Agent Skills完全指南：核心概念丨设计模式丨实战代码）。Skill 可以由大模型根据上下文自动触发，也可以由用户手动指定。在命令体系中，每个 Skill 都会被注册为一个 /skill:<name> 形式的命令，让用户能显式调用。源码在command_registry.py 中的 build_skill_commands 函数负责生成skill命令：

def build_skill_commands(
    skills: list[ExtendedSkillMetadata],
) -> list[CommandEntry]:
    """Build autocomplete entries for discovered skills."""
    return [
        CommandEntry(
            name=f"/skill:{skill['name']}",
            description=skill["description"],
            hidden_keywords=skill["name"],
            argument_hint="",
        )
        for skill in skills
        if skill["name"] not in _STATIC_SKILL_ALIASES
    ]

每个技能都会生成一个独立的命令入口。比如项目中有一个 web-research 技能，用户直接输入 /skill:web-research 就能触发该技能的执行。

注意 _STATIC_SKILL_ALIASES 这个过滤列表，它的作用是排除两个默认 Skill：remember 和 skill-creator。这两个 Skill 因为使用频率高，DeepAgents Code 为它们单独注册了顶级斜杠命令 /remember 和 /skill-creator，就不需要再挂到 /skill: 前缀下，避免重复和冗余。

2.1.3 启动命令

除了交互式的斜杠命令和技能命令，DeepAgents Code 还支持一类启动命令------它们在程序启动时自动执行，不依赖用户输入。

启动命令分为两种。一种是内置的自动更新逻辑，位于 main.py 的 _run_startup_auto_update 函数中：启动时检查是否有新版本，若有则下载安装，完成后自动重启进程。

def _run_startup_auto_update(console: Console) -> None:
    """Apply enabled auto-updates before the TUI and server start."""
    from deepagents_code.update_check import ...

    # 检查是否有新版本
    # 如果有，下载并安装
    # 安装成功后，重启进程

另一种是通过 --startup-cmd 参数指定的用户自定义命令：

dcode --startup-cmd "npm install"

这个命令会在 DeepAgents Code 启动前执行 npm install，确保项目依赖已就绪。对于需要特定环境的项目，这个能力很实用------智能体启动时自动把环境准备好，省去了手动干预的步骤。

2.2 优先级层

DeepAgents Code 命令体系中一个精妙的设计是它的优先级系统。不是所有命令都平等------有些命令必须立即执行，有些则必须排队等候。为什么需要区分优先级？核心原因在于：智能体可能正在运行状态中------正在执行工具调用、正在运行 shell 命令、或者正在连接服务器。此时用户输入命令，如果一律排队，就会造成糟糕的体验。

举个典型场景：智能体正在执行一个耗时的测试脚本，预计需要 30 秒，这时用户想退出程序，输入了 /quit。如果没有优先级机制，/quit 会被塞进消息队列，排在工具调用结果后面，用户不得不等 30 秒才能退出。有了优先级系统，/quit 被标记为 ALWAYS 级别，绕过队列立即执行。

DeepAgents Code 在 command_registry.py 中定义了 BypassTier 枚举，共五个等级：

class BypassTier(StrEnum):
    """Classification that controls whether a command can skip the message queue."""

    ALWAYS = "always"
    """Execute regardless of any busy state, including mid-thread-switch."""

    CONNECTING = "connecting"
    """Bypass only during initial server connection, not during agent/shell."""

    IMMEDIATE_UI = "immediate_ui"
    """Open modal UI immediately; real work deferred via `_defer_action` callback."""

    SIDE_EFFECT_FREE = "side_effect_free"
    """Execute the side effect immediately; defer chat output until idle."""

    QUEUED = "queued"
    """Must wait in the queue when the app is busy."""

五个优先级从高到低分别为：

优先级	说明	典型命令
ALWAYS	无论如何都立即执行	/quit、/restart、/force-clear
CONNECTING	只在服务器连接阶段可以插队	/version
IMMEDIATE_UI	立即打开模态UI，实际工作延迟执行	/model、/theme、/agents
SIDE_EFFECT_FREE	立即执行副作用，聊天输出延迟	/copy、/trace、/docs
QUEUED	必须排队等待	/clear、/help、/tokens

不同优先级对应的执行路径也不同。在 app.py 的 _submit_input 和 _can_bypass_queue 方法中，可以看到具体的处理分支。

第一步：_submit_input 直接处理 ALWAYS 级别命令

async def _submit_input(self, value: str, mode: InputMode, *, force_bypass: bool = False) -> None:
    """Submit input, fast-pathing always-immediate commands."""
    from deepagents_code.command_registry import ALWAYS_IMMEDIATE, HIDDEN_COMMANDS

    # ALWAYS_IMMEDIATE 和 HIDDEN_COMMANDS 都直接处理
    always_bypass = ALWAYS_IMMEDIATE | HIDDEN_COMMANDS

    if force_bypass or (mode == "command" and value.lower().strip() in always_bypass):
        await self._process_message(value, mode)  # 直接处理，不经过队列
        return

/quit、/restart、/force-clear 这些命令在 ALWAYS_IMMEDIATE 集合中，无论当前应用是否正在在忙别的事，直接走 _process_message，不经过任何排队逻辑。

第二步：_can_bypass_queue 判断其他优先级

def _can_bypass_queue(self, value: str) -> bool:
    """Check if a slash command can skip the message queue."""
    from deepagents_code.command_registry import (
        BYPASS_WHEN_CONNECTING, IMMEDIATE_UI, SIDE_EFFECT_FREE, STARTUP_RECOVERY_COMMANDS,
    )

    cmd = value.split(maxsplit=1)[0] if value else ""

    # STARTUP_RECOVERY: 启动失败且无 agent/shell 运行时绕过
    if (cmd in STARTUP_RECOVERY_COMMANDS
        and self._server_startup_error is not None
        and not (self._agent_running or self._shell_running)):
        return True

    # CONNECTING: 连接阶段且无 agent/shell 运行时绕过
    if cmd in BYPASS_WHEN_CONNECTING:
        return self._connecting and not (self._agent_running or self._shell_running)

    # IMMEDIATE_UI: 只有裸命令（无参数）时绕过
    if cmd in IMMEDIATE_UI:
        return value == cmd  # /model 绕过，/model gpt-4 不绕过

    # SIDE_EFFECT_FREE: 总是绕过
    return cmd in SIDE_EFFECT_FREE

第三步：在 _submit_input 中统一调度

# 如果应用忙（agent/shell正在运行、正在连接、或启动失败）
if (self._agent_running or self._shell_running or self._connecting
    or self._startup_sequence_running or self._server_startup_error is not None):
    if mode == "command" and self._can_bypass_queue(value.lower().strip()):
        await self._process_message(value, mode)  # 可以绕过，直接处理
        return
    # 不能绕过，放入队列
    self._pending_messages.append(QueuedMessage(text=value, mode=mode))
    queued_widget = QueuedUserMessage(value)
    self._queued_widgets.append(queued_widget)
    await self._mount_message(queued_widget)
    self._sync_status_queued()
    return

这个流程清晰地体现了命令体系的设计取舍：紧急命令走快速通道，普通命令排队等候，既保证了关键操作的即时响应，又不破坏任务队列的执行顺序。

2.3 命令分发与命令处理

有了命令来源和优先级，接下来看输入如何变成实际执行。当用户在输入框中输入 /命令 并按下回车后，app.py 中的 _handle_command 方法被调用。这是一个典型的集中式分发器，通过 if-elif 链将不同命令路由到对应的处理逻辑：

async def _handle_command(self, command: str) -> None:
    """Handle a slash command."""
    cmd = command.lower().strip()

    if cmd in {"/quit", "/q"}:
        self.exit()
    elif cmd == "/help":
        await self._mount_message(UserMessage(command))
        help_text = Content.assemble(...)
        await self._mount_message(AppMessage(help_text))
    elif cmd == "/agents":
        await self._show_agent_selector()
    elif cmd in {"/clear", "/force-clear"}:
        if cmd == "/force-clear":
            self._force_interrupt_active_work()
        self._pending_messages.clear()
        await self._clear_messages()
        # ... 重置线程状态
    elif cmd == "/copy":
        # 反向扫描消息列表，找到最新的可复制的助手消息
        ...

这种"单方法 + if-elif 链"的设计虽然看起来朴素，但实际效果很好：所有命令的处理逻辑集中在一处，查找和修改都很直观。简单命令（如 /quit）一行代码搞定，复杂命令（如 /clear）也按需展开，维护成本很低。技能命令（/skill:<name>）同样在这个分发链中处理：

elif cmd.startswith("/skill:"):
    await self._handle_skill_command(command)

_handle_skill_command 负责解析技能名称和参数，再调用具体的技能执行逻辑：

async def _handle_skill_command(self, command: str) -> None:
    """Handle a `/skill:<name>` command by loading and invoking a skill."""
    from deepagents_code.command_registry import parse_skill_command

    skill_name, args = parse_skill_command(command)
    await self._invoke_skill(skill_name, args, command=command)

从分发到执行的链路到这里就串起来了：_handle_command 做路由，具体方法做解析和调用，最终的技能执行逻辑承载在 _invoke_skill 中。整个分发层保持轻薄------只负责"往哪走"，不负责"怎么做"，职责边界清晰。

三、命令分发的完整流程：以/threads命令为例

前面把五层架构拆开讲了一遍，可能有点散。下面笔者用一个实际命令------/threads------把整个流程从头到尾串一遍，看看用户敲下回车之后，DeepAgents Code系统里到底发生了什么。

步骤1：命令解析

用户在输入框输入 /threads 并按下回车，_handle_command 收到原始字符串，先做基本的清洗------去掉首尾空白、转小写，得到标准化的命令名。

async def _handle_command(self, command: str) -> None:
    """Dispatch a slash command."""
    command = command.strip()  # 去除首尾空白

步骤2：查找注册信息

去 command_registry.py 的 COMMANDS 元组里查找 /threads 的定义：

SlashCommand(
    name="/threads",
    description="Browse and resume past conversations",
    bypass_tier=BypassTier.QUEUED,
    hidden_keywords="history sessions continue",
)

这里最关键的信息是 bypass_tier: QUEUED------说明这个命令不能插队，必须排队等候。

步骤3：优先级判断

_can_bypass_queue 检测到当前应用正处于忙碌状态（_agent_running 为 True），于是调用 _can_bypass_queue 检查 /threads 是否满足绕过条件。QUEUED 级别不在任何绕过集合中，判定结果为不绕过，命令被送入消息队列。

def _can_bypass_queue(self, command: str) -> bool:
    """Check if a command can bypass the message queue."""

步骤4：队列等待

_pending_messages 列表中新增一条待处理记录，同时 UI 上会显示一个"排队中"的状态提示，让用户知道命令已被接收、正在等待执行。

else:
    # 放入消息队列
    await self._queue_message(command)

步骤5：命令执行

当前正在运行的任务结束后，消息队列的消费逻辑被触发，/threads 从队列头部取出，再次进入 _handle_command 分发。

elif cmd == "/threads":
    await self._show_thread_selector()

步骤6：显示线程列表并选择

打开一个模态框，显示所有历史线程,用户通过方向键选择线程后，按下回车。

步骤7：恢复线程

用户选择线程后，调用 _resume_thread 方法恢复线程。这部分的实际工作已经在 LangChain DeepAgents 速通指南（十一）------ DeepAgents Code 记忆与状态管理 展示过了，大家可参考上篇文章。

同样的逻辑也适用于其他命令。比如 /model 的执行流程如下图所示，大家可以对照源码自己梳理一遍，权当巩固：

四、命令系统的设计哲学

技术细节讲完了，最后聊几个设计上的考量。在笔者看来，DeepAgents Code 的命令体系主要围绕四个关键词展开。

4.1 效率优先

命令体系的首要目标是让用户少敲键盘、少等待 。斜杠命令本身就是一次操作直达目标，不需要和智能体来回对话才能完成一件事。自动补全和模糊匹配进一步降低了记忆负担------用户不需要精确记住每个命令的名字，敲个大概就能命中。而优先级系统的存在，则是为了保证用户在紧急场景下不用等：智能体再忙，/quit 也得立刻响应。这些设计指向同一个方向：用户的每一秒都不该被浪费在等待上。

4.2 安全与容错

终端智能体有一个天然的风险：它可能执行危险的 shell 命令、修改重要文件、或者陷入死循环。命令体系在安全层面的考虑体现在两个方面。

一是逃生通道 ：/quit、/restart、/force-clear 这些命令拥有最高优先级，无论智能体处于什么状态------正在执行工具调用、正在运行 shell、甚至卡在某个循环里------用户都能强行退出或重启。这相当于给用户留了一个物理上的"电源键"。

二是故障恢复 ：当服务器启动失败或环境出问题时，STARTUP_RECOVERY_COMMANDS 集合中的命令（如 /install、/reload）仍然可以执行。用户在出错状态下依然有自救手段，不需要直接关掉终端重来。

4.3 可扩展性

DeepAgents Code 的命令体系不是封闭的。Skill 系统允许用户把自己的能力封装成命令，/skill:<name> 就是统一的入口。MCP 的接入则进一步打开了外部工具的集成通道。这种"核心命令 + 插件扩展"的模式，让这套命令体系能在不修改主代码的情况下不断生长，适应不同团队、不同项目的差异化需求。

4.4 用户体验

命令体系的每一个细节都体现了对用户体验的关注。自动补全的模糊匹配让用户少记几个单词，help 屏幕用友好的描述替代冰冷的命令列表，欢迎横幅里的随机提示偶尔能给用户一点小惊喜。这些细节单独看都不起眼，但堆在一起，就构成了"这个工具用起来很顺手"的整体感受。

五、DeepAgents Code 的工程化设计哲学

命令体系本身只是冰山一角。把代码往下翻一层，大家会发现 DeepAgents Code 在工程实现上还埋了不少"防御性的设计"。这些细节在功能列表里看不到，但正是它们把"能跑"的代码变成了"敢上生产"的代码。下面挑几个有代表性的聊一聊。

5.1 Unicode安全防护

终端是文本交互的主战场，而文本天然携带攻击面。unicode_security.py 这个文件专门处理一类容易被忽视的安全风险：控制字符和同形字攻击。先看控制字符。双向格式化字符（BiDi）可以在终端中改变文本的显示顺序，攻击者可以利用它构造出"看起来是 A、实际执行是 B"的命令。Unicode 安全模块直接冻结了这些危险码点：

_DANGEROUS_CODEPOINTS: frozenset[int] = frozenset({
    # BiDi 双向格式化控制字符（嵌入、覆盖、弹出）
    *range(0x202A, 0x202F),
    # 零宽和不可见格式化控制字符
    0x200B,  # 零宽空格
    0x200C,  # 零宽非连接符
    0xFEFF,  # 零宽不中断空格 / BOM
})

# 检测西里尔字母和希腊字母的同形字（confusables）
CONFUSABLES: dict[str, str] = {
    "\u0430": "a",  # 西里尔字母 а → 拉丁字母 a
    "\u0435": "e",  # 西里尔字母 е → 拉丁字母 e
    "\u043e": "o",  # 西里尔字母 о → 拉丁字母 o
}

当用户在输入框中粘贴内容时，系统会扫描这些危险字符，要么自动规范化，要么给出警告------在攻击发生之前就把门关上。

5.2 SSRF防护与DNS固定

终端智能体经常需要访问外部 URL（抓取文档、读取 API 等），这就引入了 SSRF（服务端请求伪造）的风险。tools.py 中的 fetch_url 工具实现了一套多层防护。

第一层是 IP 地址过滤。在发起任何网络请求之前，先解析目标域名，检查解析出的 IP 是否属于危险范围------私有地址、回环地址、链路本地地址（包括云厂商的 IMDS 元数据服务）、多播地址、保留地址，全部拒绝：

def _is_blocked_ip(ip: ipaddress.IPv4Address | ipaddress.IPv6Address) -> bool:
    """拒绝私有、回环、链路本地、保留、多播地址。"""
    # 处理 IPv4-mapped IPv6（如 ::ffff:127.0.0.1）
    if isinstance(ip, ipaddress.IPv6Address):
        if ip.ipv4_mapped is not None:
            ip = ip.ipv4_mapped
        elif ip.sixtofour is not None:
            ip = ip.sixtofour  # 处理 6to4 隧道地址

    return (
        not ip.is_global      # 非全局可路由
        or ip.is_private      # 私有地址（RFC1918）
        or ip.is_loopback     # 回环地址（127.0.0.0/8）
        or ip.is_link_local   # 链路本地（169.254.0.0/16，包括云 IMDS）
        or ip.is_reserved     # 保留地址
        or ip.is_multicast    # 多播地址
        or ip.is_unspecified  # 未指定地址（0.0.0.0/::）
    )

第二层更有意思------DNS 固定。常见的攻击手法是 TOCTOU（Time-of-Check-Time-of-Use）：系统先解析域名、检查 IP 是否安全，检查通过后、实际建立连接之前，攻击者通过 DNS 重绑定把域名指向一个内网 IP，从而绕过检查。DeepAgents Code 的做法是：检查通过后，把域名"钉死"在已验证的 IP 列表上，后续连接只走这些 IP，不再重新解析：

@contextlib.contextmanager
def _pinned_dns(hostname: str, allowed_ips: list[str]) -> Iterator[None]:
    """强制出站连接只使用已验证的 IP。"""
    # 补丁 urllib3 的连接创建函数，固定到已验证的 IP
    def patched(address, *args, **kwargs):
        host, port = address[0], address[1]
        if host != hostname:
            return original(address, *args, **kwargs)
        # 只尝试已验证的 IP，按顺序尝试
        for ip in allowed_ips:
            try:
                return original((ip, port), *args, **kwargs)
            except OSError as exc:
                last_exc = exc
        raise last_exc

    urllib3_connection.create_connection = patched
    try:
        yield
    finally:
        urllib3_connection.create_connection = original  # 恢复原函数

验证和连接之间再无 DNS 查询的机会，攻击窗口被彻底堵死。

5.3 线程切换的预取机制

在 app.py 的 _resume_thread 方法中，切换会话线程时，常规做法是先清空当前对话、再加载目标线程。但如果加载失败了怎么办？用户当前正在看的内容已经没了，新的也没加载进来，用户卡在一个空白状态里，只能凭记忆恢复。DeepAgents Code 的做法是先预取：

async def _resume_thread(self, thread_id: str) -> None:
    # 预取线程历史（避免加载失败时清空当前对话）
    prefetched_payload = await self._fetch_thread_history_data(thread_id)

    try:
        # 清空当前对话
        await self._clear_messages()
        # 切换到新线程
        self._session_state.thread_id = thread_id
        await self._load_thread_history(preloaded_payload=prefetched_payload)
    except Exception as exc:
        # 错误处理：回滚到前一个线程
        self._session_state.thread_id = prev_thread_id
        await self._mount_message(AppMessage(f"Failed to switch: {exc}"))

这个顺序调整看似不起眼，但背后是一个重要的工程原则：状态变更之前，先确认目标状态可达。预取成功意味着目标数据可用，此时再切换是安全的；预取失败时，当前对话完好无损，用户没有任何损失。

这三个例子只是随手摘出来的。还有很多的功能设计，单独看都不算什么大功能，但堆在一起，就构成了 DeepAgents Code 的工程底气------安全的生产级应用！

六、总结

从第九篇到第十二篇，笔者用四篇文章带大家深入拆解了DeepAgents Code的源码。包括DeepAgents Code项目架构 、Agent-Server核心原理 、状态与记忆管理 、命令体系与工程实践 。这些内容覆盖了构建一个生产级编程智能体所涉及的主要技术维度。但说到底，读源码不是为了记住某一行代码怎么写，而是去理解设计者在当时条件下做了什么选择、为什么做这个选择。每个工程决策都是取舍的结果------理解了取舍，这些经验就能内化成你自己的判断力，而不是停留在"别人这么写我也这么写"的层面。

关于DeepAgents Code的源码解读系列本篇文章就结束啦，感谢大家跟我走完这段源码之旅。如果这四篇文章对你有所启发，欢迎分享给身边的朋友。

本系列相关内容均列于笔者的专栏《深入浅出LangChain&LangGraph AI Agent 智能体开发》，该专栏适合所有对智能体开发感兴趣的学习者，无论之前是否接触过 LangChain。该专栏基于笔者在实际项目中的深度使用经验，系统讲解了使用LangChain/LangGraph如何开发智能体，目前已更新 49 讲，并持续补充实战与拓展内容。欢迎感兴趣的同学关注笔者的掘金账号与专栏，也可关注笔者的同名微信公众号大模型真好玩 ，每期分享涉及的代码均可在公众号私信: LangChain智能体开发免费获取。