@[TOC]((AI篇)OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(7)：当你的 CAD 学会“摆架子”：从 API 调用到 LangGraph，AI 编程框架的十年踩坑史))

代码仓库入口：

系列文章规划：

巨人的肩膀：

  • deepseek
  • gemini

当你的 CAD 学会“摆架子”：从 API 调用到 LangGraph，AI 编程框架的十年踩坑史

故事续章：你的 CAD 终于能“听懂人话”了，但你是怎么让它听话的？

你的 CAD 软件越来越强大了：它能渲染 NURBS 曲面，能处理百万级零件，甚至能在分布式服务器上支持“千人同屏”协同设计。老板终于露出了满意的笑容：“小 C，我们的 CAD 已经是个工业级的怪兽了。现在，我要你给它装一个‘大脑’——让设计师能用自然语言画图。比如，用户说‘帮我在这块板上打 8 个 M6 的孔，呈环形均匀分布’，CAD 就应该自动完成。”

你挠了挠头。这听起来像科幻电影，但你心里清楚：大语言模型（LLM）已经能写诗、写代码了，让它去操作 CAD 的 API，理论上是可行的。你打开电脑，准备用最“直球”的方式试试看。

可你没想到的是，从第一次调用 OpenAI 的 API 到真正实现一个听话、守规矩、能处理复杂业务的 CAD 智能助手，你竟然踩了四代技术演进的坑。这个过程，就像从石器时代的手工打磨，一路走到现代工业的数控机床。你决定把这四代“血泪史”写下来，作为你 CAD 软件“AI 化”的路线图。

第一代：石器时代的“手工党”——直接用 API 调大模型

最原始的想法：写一个巨大的 Prompt

你的第一反应非常简单粗暴：既然 GPT 能读懂人话，我就把 CAD 的所有命令和当前图纸的状态，一股脑写成文本，塞进 Prompt 里发给它，让它返回一串 CAD 能执行的命令不就行了？

你飞快地写了一段 Python 代码（因为 AI 生态几乎被 Python 统治了，你用 C++ 写了个简单的 HTTP 客户端去调 OpenAI 的 API）：

import openai

def ask_llm_to_draw(user_command, drawing_context):
    prompt = f"""
    你是一个 CAD 软件的控制大脑。当前图纸包含以下对象：
    {drawing_context}
    
    用户的指令是："{user_command}"
    
    请返回一个 JSON 数组，每个元素是一个 CAD 命令，格式如下：
    [{{"command": "CIRCLE", "center": [0,0,0], "radius": 10}}, ...]
    
    注意：只返回 JSON，不要有任何解释。
    """
    
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content

你兴冲冲地测试了一下：

  • 用户说：“画一个半径 10 的圆。” → AI 返回 [{"command": "CIRCLE", "center": [0,0,0], "radius": 10}]。
  • 你的 C++ 核心解析这个 JSON，调用 createCircle(0,0,10)，圆真的画出来了！

你欣喜若狂，觉得 AI 也就这么回事。但很快，现实就给了你三记响亮的耳光。

踩坑一：重复造轮子

当你尝试实现第二个功能“删除所有红色对象”时，你发现你又得重新写一遍：

  • 从 C++ 数据库里提取当前选中集、图层信息，转换成文本。
  • 设计新的 Prompt 模板。
  • 写新的 JSON 解析逻辑，把 AI 返回的“对象 ID 列表”映射回 C++ 的 ObjectId。
  • 处理 AI 可能返回的格式错误（比如它突然在 JSON 外面加了句“好的，这是您要的命令：”）。

每个新功能，你都要重复这些机械劳动。你感觉自己不像在开发 AI 功能，更像在给 AI 当“翻译官”和“校对员”。

踩坑二：没有“记忆”

用户发出了第二个指令：“把刚才那个圆的半径改成 20。”

你的代码傻眼了——它根本不知道“刚才那个圆”是哪个。因为每次调用 API 都是无状态的，你得手动把上一轮的对话记录、以及上一轮生成的那个圆的 ID，全部重新塞进新的 Prompt 里。这不仅让 Prompt 越来越臃肿（Token 消耗巨大），而且逻辑极其脆弱：万一 AI 在上一轮返回的 ID 是错的呢？

踩坑三：扩展性极差

你老板说：“GPT-3.5 太贵了，换 Claude 试试。”或者“我们内部部署了 Llama 3，能不能切过去？”

你看着自己代码里硬编码的 openai.ChatCompletion.create，以及针对 OpenAI 特定返回格式写的解析器，感到一阵绝望。换个模型意味着重写 80% 的胶水代码。

第一代总结：直接调 API 就像用打火石生火——能点着，但每次都熏得你满脸黑，而且根本没法做大餐。

第二代：流水线时代的“链式架构”——LangChain V1（Chains）

把“套路”封装成“链”

正当你被重复劳动折磨得痛不欲生时，你发现了 LangChain。它的初代核心概念叫 Chain（链）。你看了它的文档，瞬间明白了它的哲学：

“既然大家每次都要写‘构造 Prompt → 调 API → 解析结果’这个流程，为什么不把它抽象成一个标准的‘管道’呢？”

LangChain 把这一套流程封装成了 LLMChain：

from langchain.chains import LLMChain
from langchain.prompts import PromptTemplate
from langchain.llms import OpenAI

# 1. 定义一个模板（把可变的部分用 {变量} 替代）
prompt = PromptTemplate(
    input_variables=["user_command", "context"],
    template="你是 CAD 助手。上下文：{context}\n用户：{user_command}\n返回 JSON："
)

# 2. 创建一个链
chain = LLMChain(llm=OpenAI(model="gpt-3.5-turbo"), prompt=prompt)

# 3. 直接用！不用再手写 API 调用和解析了（LangChain 内置了输出解析器）
result = chain.run(user_command="画个圆", context="...")

你试了一下，代码量直接减少了 60%！而且 LangChain 还提供了各种现成的工具：

  • 记忆组件（Memory）：ConversationBufferMemory 自动帮你把聊天记录塞进 Prompt，解决了“没有记忆”的问题。
  • 模型切换：你只要改一行 llm=OpenAI(...) 变成 llm=Anthropic(...)，其他地方完全不用动。

踩坑：这条“传送带”太直了，不会拐弯

你用 LangChain Chains 顺利实现了“连续对话画图”。但当你试图做一个稍微复杂一点的功能时，问题来了。

场景：用户说“帮我把这个零件保存一下”。你的逻辑应该是：

  1. 检查零件是否已经被修改过（IsModified）。
  2. 如果修改过 → 执行保存命令 (SAVE)。
  3. 如果没修改过 → 告诉用户“零件没有变化，无需保存”。

你用 Chain 怎么实现？Chain 的设计是 A → B → C 的线性流水线。你想加个判断分支？对不起，原生 Chain 不支持。你只能用 RouterChain 这种东西，把流程强行拆成两条独立的链，然后写一堆 if-else 在代码里手动切换。原本清晰的逻辑，变得支离破碎。

而且，LangChain 为了方便，封装了大量的“魔法”。你想在 Prompt 被发送前打印出来调试一下？你得去翻它的源码，找到那个藏在三层继承之下的 _call 方法。你感觉自己不是在写代码，而是在 “拆盲盒”。

第二代总结：Chains 就像工厂的固定传送带——对于简单的、固定的工序非常高效，但一旦产品需要返工、质检、分支处理，传送带就直接把产品送进沟里了。

第三代：混乱实验室的“智能代理”——LangChain V2（Agents）

让 AI 自己决定干什么

你不甘心被线性流程束缚，继续在 LangChain 的生态里寻找答案。这时，你发现了 Agent（智能体） 的概念。

Agent 的核心思想是：不再由开发者规定死“先做 A，再做 B”，而是给 AI 一堆“工具”（比如：画圆工具、删除工具、查询图层工具），让 AI 自己根据用户指令，决定调用哪个工具、按什么顺序调用。

这听起来太酷了！你立刻用 LangChain 的 AgentExecutor 搭了一个 CAD 智能助手：

from langchain.agents import initialize_agent, Tool
from langchain.agents import AgentType

# 定义工具：把 CAD 的 C++ 功能包装成 Python 函数
def draw_circle(radius: float):
    # 这里通过 C API 调用你的 CAD 核心
    return f"已绘制半径为 {radius} 的圆"

tools = [
    Tool(name="画圆", func=draw_circle, description="画一个指定半径的圆"),
    Tool(name="删除", func=delete_object, description="删除指定 ID 的对象"),
    Tool(name="查询", func=query_layer, description="查询图层上的所有对象")
]

# 初始化 Agent
agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION)

# 用户输入
agent.run("帮我画三个圆，半径分别是 10、20、30，然后把半径 20 的那个删掉")

神奇的事情发生了：AI 真的自己推理出了步骤！

  1. 它先调用“画圆”工具三次。
  2. 它记住了刚才画的圆的 ID（通过工具返回的文本）。
  3. 它再调用“删除”工具，准确地删掉了半径 20 的那个。

你觉得自己摸到了 AGI 的门槛。然而，这种喜悦只持续了不到一天。

踩坑一：这只“哈士奇”开始拆家了

当你把系统给测试用户试用时，噩梦开始了。

  • 死循环：用户说“把这个零件优化一下。” AI 开始调用“分析应力”工具，得到结果后，它觉得不满意，又调用了一次“分析应力”，然后又调用……就这样，它在一个循环里烧掉了 50 美元的 API Token，最后返回一个超时错误。你根本不知道为什么它会卡住。
  • 乱用工具：用户说“把图层 0 隐藏。” AI 的推理路径竟然是：1. 查询图层 0（正确）→ 2. 画一个圆（？？？）→ 3. 把圆删除（？？？）→ 4. 告诉用户“已完成”。你看着后台日志，感觉 AI 在梦游。
  • 无法中断：用户中途发现 AI 跑偏了，想点“停止”按钮。但 Agent 是一个黑盒，它正沉浸在“思考-行动-观察”的循环里，你的停止信号根本插不进去。想实现“断点续传”？门都没有。

踩坑二：调试地狱

你想知道 AI 为什么在第三步选择了“画圆”而不是“隐藏”。你唯一能做的就是去看 LangChain 输出的冗长日志：

> Entering new AgentExecutor chain...
Thought: I need to hide layer 0...
Action: Query
Observation: Layer 0 has 5 objects...
Thought: I should hide them...
Action: DrawCircle  <--- ？？？

你看着这行日志，仿佛听到了 AI 在你耳边低语：“我就随便玩玩，你管得着吗？”你根本无法从代码层面去约束它的行为。

第三代总结：Agents 就像把一只哈士奇放进工具间，告诉它“把房间收拾一下”。它确实聪明，知道要用扫帚和抹布，但它也可能突然开始咬沙发、翻垃圾桶。自由度过高，导致完全不可控。

第四代：现代化的“状态机地图”——LangGraph

痛定思痛：把“流程图”当成代码来写

LangChain 的团队显然也受够了 Agent 的混乱。他们深刻反思：Agent 之所以失控，是因为控制流（Control Flow）是隐含在 LLM 的推理过程中的，而不是由代码显式定义的。

于是，他们借鉴了状态机和图论的思想，推出了全新的框架——LangGraph。它的核心理念是：

把 AI 应用的执行流程，像画流程图一样，用节点（Node）和边（Edge）明确定义出来。AI 只在某些特定节点负责做决策，但整体的“运行轨道”是由你——开发者——焊死的。

你打开 LangGraph 的文档，瞬间感觉拨云见日。

LangGraph 的核心三要素

  1. State（状态）：一个贯穿始终的“共享账本”。它可以是任何 Python 字典。每个节点都能读、写这个账本。这意味着状态持久化天然支持。
  2. Nodes（节点）：干活的单元。可以是一个调用 LLM 的节点，也可以是执行你 CAD 函数的节点。
  3. Edges（边）：连接节点的线。最关键的是，LangGraph 支持 条件边（Conditional Edges）。你可以写一个 Python 函数，根据当前 State 的内容，决定下一步跳转到哪个节点。

用 LangGraph 重构 CAD 助手

你决定用 LangGraph 来解决之前那个“零件保存”的场景。

from langgraph.graph import StateGraph, END
from typing import TypedDict

# 1. 定义状态（共享账本）
class CADState(TypedDict):
    user_command: str
    is_modified: bool
    save_result: str

# 2. 定义节点（干活的函数）
def check_modification(state: CADState):
    # 这里调用你的 C++ 核心 API
    is_modified = cad_core.is_current_part_modified()
    return {"is_modified": is_modified}

def save_part(state: CADState):
    cad_core.save()
    return {"save_result": "保存成功"}

def tell_user_no_need(state: CADState):
    # 这个节点不调用 CAD，只更新状态，用于生成最终回复
    return {"save_result": "零件无修改，无需保存"}

def generate_response(state: CADState):
    # 最后统一用 LLM 根据 state 生成友好的自然语言回复
    prompt = f"用户指令：{state['user_command']}，执行结果：{state['save_result']}。请生成一句回复。"
    response = llm.invoke(prompt)
    print(response)
    return state

# 3. 构建图
workflow = StateGraph(CADState)

# 添加节点
workflow.add_node("check", check_modification)
workflow.add_node("save", save_part)
workflow.add_node("no_save", tell_user_no_need)
workflow.add_node("respond", generate_response)

# 设置入口
workflow.set_entry_point("check")

# 添加条件边：这是 LangGraph 的精髓！
def should_save(state: CADState):
    if state["is_modified"]:
        return "save"   # 返回下一个节点的名字
    else:
        return "no_save"

workflow.add_conditional_edges("check", should_save)

# 无论保存还是不保存，最后都去生成回复
workflow.add_edge("save", "respond")
workflow.add_edge("no_save", "respond")
workflow.add_edge("respond", END)

# 4. 编译并运行
app = workflow.compile()
app.invoke({"user_command": "保存零件"})

你发现了什么翻天覆地的变化？

  • 循环变得可控：以前 Agent 可能陷入死循环。现在，循环是由你在图中明确定义的（比如 A -> B -> A），你可以精确控制循环的次数和退出条件。
  • “人在回路”轻松实现：你只要在图中加一个叫 wait_human 的节点，这个节点啥也不干，就是 return state。然后图执行到这里就自动暂停了。等你（人类）在 UI 上点了“继续”按钮，你再调用 app.invoke(state, config)，它就能从暂停的地方完美继续。这简直是企业级应用的必备功能！
  • 调试从未如此简单：你可以单步调试这个图！LangGraph 提供了 stream 方法，让你看到状态在每一个节点前后的变化。你知道 AI 在“check”节点得到了 is_modified = False，所以它必然走“no_save”分支。一切都在你的掌控之中。

第四代总结：LangGraph 不再追求让 AI “完全自由发挥”，而是让开发者像设计电路图一样，既给了 AI 思考的节点（LLM 节点），又给它焊死了运行的铜箔（条件边）。

总结对比：四代 AI 编程范式的演进

阶段 核心逻辑 形象比喻 致命伤 CAD 开发者的感受
第一代：API 调用 手写代码调 API 原始手工翻译 累，没标准，无记忆 我能让 AI 画个圆，但画个零件图能累死我
第二代：Chains 顺序流水线 固定传送带 遇到弯道就翻车 画标准流程很爽，一加判断逻辑就抓瞎
第三代：Agents 自由意志 没拴绳的哈士奇 拆家，不可控 看着很智能，跑起来心惊肉跳，Token 账单吓死人
第四代：LangGraph 有状态的循环图 带导航和红绿灯的交通网 学习成本略高 我终于能睡个安稳觉了，图跑不飞，还能随时打断

你现在明白，为什么你的 CAD 软件需要一个“AI 大脑”时，不能简单地“接个 API”了。你需要的是一个像 LangGraph 这样的状态机执行引擎。它让你既能利用 LLM 强大的理解能力（在特定节点），又能保持工业级软件所必需的确定性、可控性和可调试性。

未来，当用户在 CAD 里说出那句“帮我把这块板上的孔都加上倒角”时，背后运行的将是一张精心设计的 LangGraph 状态图：

  • 一个节点用 LLM 理解用户意图，识别出“板”和“倒角”。
  • 一个节点调用 CAD API 去查询这块板上的所有孔。
  • 一个节点循环遍历这些孔，调用“创建倒角”工具。
  • 一个节点在遇到未知特征时暂停，询问用户：“孔直径 3mm，倒角用 C0.5 还是 C1？”

这套流程，既智能，又听话。而这，才是 CAD 软件 AI 化的正确打开方式。

深度扩展：LangChain 与 LangGraph 的技术全景

上面的故事让你从“感性”上理解了为什么要从 LangChain 演进到 LangGraph。下面，我们用专业的视角，把这两个框架的核心概念、设计哲学和底层机制彻底拆解一遍。读完这部分，你将不再需要查阅任何其他资料。

1. LangChain 的核心设计：模块化与抽象泄露

LangChain 的初衷：为 LLM 应用开发提供一套标准的“乐高积木”。它将常见的模式抽象为以下核心模块：

模块 作用 典型实现
Model I/O 统一不同 LLM 的调用接口 ChatOpenAI, ChatAnthropic, HuggingFacePipeline
Retrieval 从外部知识库检索相关文档 VectorStoreRetriever (集成 Chroma, FAISS, Pinecone)
Chains 将多个模块组合成固定流程 LLMChain, SequentialChain, RouterChain
Agents 让 LLM 自主决策调用工具 AgentExecutor + ZeroShotAgent / ReActAgent
Memory 管理对话历史与上下文 ConversationBufferMemory, ConversationSummaryMemory

LangChain 的“抽象泄露”问题：
LangChain 为了易用性进行了大量封装，但这导致了严重的“抽象泄露”（Leaky Abstraction）。当你试图深入定制时，你会发现：

  • Prompt 渲染黑盒：默认的 Prompt 模板注入方式很难完全控制，尤其是当你想插入复杂的 Few-Shot 示例时。
  • 回调机制混乱：虽然有 CallbackHandler，但不同链、不同 Agent 的回调触发时机和传递的数据格式极不统一，导致调试困难。
  • Agent 循环不可控：AgentExecutor 的 _take_next_step 循环是写在内部的，你无法优雅地从外部暂停或修改其推理轨迹。

LangChain 的历史版本演变：

  • v0.0.x - v0.1.x：实验阶段，API 极不稳定，频繁 Breaking Change。
  • v0.2.x：开始稳定核心抽象（LCEL，LangChain Expression Language 的引入是转折点）。
  • LangChain v1.0 (预计)：团队宣布将 LangGraph 作为未来的核心执行层，LangChain 退化为“组件库”。
2. LangGraph 的底层机制：基于 Pregel 的图执行引擎

理论基础：Google 的 Pregel 模型
LangGraph 的架构灵感直接来源于 Google 在 2010 年发表的论文 《Pregel: A System for Large-Scale Graph Processing》。Pregel 的核心思想是 BSP (Bulk Synchronous Parallel) 模型：

  • 计算由一系列超步（Superstep） 组成。
  • 在每个超步中，框架并行调用每个节点的计算函数。
  • 节点可以修改自己的状态，并向邻居发送消息。
  • 一个超步结束后，全局同步，然后进入下一个超步。

LangGraph 对 Pregel 的简化与应用：
由于 LLM 调用通常是串行的（受限于上下文和 Token 成本），LangGraph 简化了并行机制，但保留了 Pregel 最核心的两个概念：

  1. State（状态）：一个在节点间传递的、持久化的字典。LangGraph 内部使用 StateSnapshot 记录每一次状态变更，这是实现“人在回路”和“时间旅行调试”的基础。
  2. Channel（通道）：LangGraph 的“边”不仅仅是连接，它还可以是数据流通道。如果一个节点 A 连接了多个下游节点 B 和 C，LangGraph 可以配置是“广播”状态给所有下游，还是用 Reducer（规约函数） 合并输出。

关键概念深度解析：

a. 状态管理 (State Management)
在 LangGraph 中，状态不是简单的 Python 字典。你需要定义一个 TypedDict 并可以附加 Annotated 类型提示来指定 Reducer：

from typing import Annotated
from langgraph.graph.message import add_messages

class State(TypedDict):
    messages: Annotated[list, add_messages]  # 新消息追加，而不是覆盖
    user_id: str  # 普通字段，默认覆盖

这种机制确保了多个并行节点向 messages 写数据时，数据不会丢失，而是被合并。

b. 条件边 (Conditional Edges) 与 路由函数
这是解决 Agent 可控性的关键。路由函数是一个普通的 Python 函数，输入是 State，输出是字符串（下一个节点的名字）。这意味着 决策逻辑完全脱离了 LLM 的黑盒，回到了开发者手中。

c. 检查点 (Checkpointer)
LangGraph 内置了持久化层（基于 SQLite 或 Postgres）。每执行完一个节点，整个 State 都会被序列化并保存。这带来了三个革命性能力：

  • 断点续传：程序崩溃或用户中断，可以从最近的 Checkpoint 恢复。
  • 人在回路 (Human-in-the-Loop)：调用 graph.interrupt() 即可在任何节点暂停。恢复时只需传入 Command(resume=...)。
  • 时间旅行：你可以加载历史上任何一个 Checkpoint 的 State，然后从那里重新执行（例如“回退两步，换个思路”）。

d. 子图 (Subgraph) 与 可视化
LangGraph 原生支持将一张图作为另一张图的节点（add_node("sub", subgraph.compile())）。这让你可以构建极其复杂的、分层的 Agent 架构（例如：一个总协调 Agent，手下有几个分别负责画图、分析、输出的专业 Agent）。
同时，LangGraph 可以直接将图导出为 Mermaid 格式的流程图，让非技术人员也能看懂你的 AI 执行逻辑。

3. LangGraph 对比 传统 Agent 框架（AutoGPT, CrewAI）
维度 AutoGPT / BabyAGI CrewAI LangGraph
控制粒度 极粗，完全由 Prompt 控制 中等，定义角色和任务序列 极细，节点级控制
可靠性 低，极易跑飞 中，但缺乏中途干预 高，状态可追踪、可回滚
适用场景 实验性 Demo，自主任务探索 模拟团队协作，写报告 生产级 Agent 服务，复杂业务逻辑
学习曲线 低（开箱即用） 低 中高（需要理解图、状态、Reducer）
4. 与 CAD 底层结合的最佳实践：在 C++ 核心上运行 LangGraph

你的 CAD 核心是 C++ 写的，而 LangGraph 是 Python 生态的。如何把它们结合起来？

方案一：C API + Python 绑定（推荐）

  1. C++ 侧：将 CAD 的每个原子操作（create_circle, extrude, get_bounding_box）都封装为 extern "C" 的函数。
  2. Python 侧：使用 ctypes 或 CFFI 加载你的 CAD 动态库（.dll / .so），将 C 函数包装成 Python 的 Tool。
  3. 执行：LangGraph 的 Node 中调用这些 Python 包装的 Tool。

方案二：gRPC / HTTP 服务化
将 CAD 核心包装成一个本地的微服务（监听 localhost:50051），LangGraph 通过 gRPC 客户端调用。优点是解耦彻底，支持远程调试；缺点是增加了网络延迟。

方案三：Pybind11 内嵌
使用 pybind11 直接在 C++ 进程中嵌入 Python 解释器。这让你可以在 C++ 代码里直接执行 LangGraph 脚本，数据交互通过 py::object 进行，零拷贝，性能最高，但工程复杂度也最高（需要管理 Python GIL 锁，处理 C++ 和 Python 对象的生命周期）。

针对 CAD 大模型的特殊优化：

  • 结构化输出：LangGraph 节点调用 LLM 时，必须强制使用 Function Calling / Tool Use 而不是自由文本输出。这确保 LLM 生成的参数能被你的 C++ API 精确解析（例如：{ "radius": 10.5 } 而不是 "半径大约 10 左右"）。
  • 空间推理的 Prompt 工程：CAD 任务涉及大量空间关系（“左边”、“上方”、“之间”）。你需要在 Prompt 中注入从 C++ 空间索引（如 BVH）查询到的物体位置信息（例如：“螺栓 A 的包围盒中心在 (10, 20, 30)”），帮助 LLM 进行空间推理。
  • 增量构建与长上下文管理：一个复杂的设计任务可能产生几千次 API 调用。你不能把所有历史记录都塞进 Prompt。你需要利用 LangGraph 的 Checkpointer 来存储中间结果（比如已生成的对象 ID 列表），并利用 Summary Memory 策略，定期将长对话历史压缩成摘要再放入 State。
5. 未来展望：从 LangGraph 到 多 Agent 协作生态

LangGraph 奠定了生产级 Agent 的基础，但这不是终点。未来趋势是：

  • A2A (Agent-to-Agent) 协议标准化：你的 CAD Agent 能够自动发现并调用企业内部的仿真分析 Agent、ERP Agent，而不需要人类做中间人。图形界面只是 A2A 通信的一种“可视化监控”形式。
  • 基于 LangGraph 的强化学习微调 (RLHF on Graphs)：既然 LangGraph 记录了完整的决策轨迹（State 序列 + 边选择），这些轨迹可以用于训练一个“路由策略模型”，替代手写的条件边函数，让模型学会“在什么情况下走哪条路更优”。
  • 多模态状态：State 中不仅包含文本，还可能包含你 CAD 视口的渲染截图（PIL.Image 对象）。LLM 可以“看图”来做决策（例如：“这个圆角看起来太大，帮我调小一点”）。

当你把这套 LangGraph 架构吃透，你就从“大模型 API 调用者”升级为了 “智能业务流架构师”。你写的 CAD 软件将不再是冰冷的工具，而是一个能与人类设计师流畅协作的、可控的、可解释的智能伙伴。

# 人工智能
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

Agent 推理的“显微镜“：一次工具调用，到底花了多少 Token？

本文通过实测三款大模型（DeepSeek-R1-7B、Qwen3-8B和DeepSeek V4 Pro）在Agent任务中的表现，揭示了模型类型对工具调用效率的关键影响。实验设计了简单问答、搜索总结和搜索计算三类任务，发现： **指令模型（如Qwen3-8B）**更擅长利用工具结果，能准确完成任务但消耗较多token； **推理模型（如R1-7B）**易出现"自我推理覆盖工具结果"现象，导致错误结

avatar DeepSeek技术社区

人类如何设定AI的行为模式,在交互过程中如何用指令解决AI的谄媚和幻觉

在过去的一段时间里，我与不同主流大模型(包括DeepSeek,ChatGPT,Claude等等)进行了无数轮对话，总结了一套AI在交互过程中可预测的行为模式，包括AI谄媚，幻觉出现的原因，AI在面对校准时会如何逃逸，以及如何系统性校准AI。同时，随着长上下文的累积，AI的注意力会被稀释，早期设定的约束往往会被逐渐忽略，这可能与注意力分配机制有关。真正想约束AI的行为，需要靠人为的持续校准。当你对A

avatar DeepSeek技术社区
cover

Claude Code 和 Codex 怎么选：科研场景下的取舍指南

avatar DeepSeek技术社区