这次我们来看一个大模型 Agent 开发的学习与落地路径。标题里四个关键词——LangChain V1.0、Harness 工程、智能体工具、TextToSQL——基本覆盖了从框架、工程化、工具链到业务项目的完整闭环。市面上讲 LangChain 用法的教程很多但能同时把“V1.0 新架构”“Harness 工程化思路”“工具调用细节”和“NL2SQL 项目落地”串在一起的确实不多。先说一个核心判断现在 Agent 开发最大的问题不是模型能力不够而是工程化程度太低。很多人还在“写 Prompt 拼 Chain”遇到多步任务、工具调用失败、长期运行不稳定就不知道怎么处理了。这正是 Harness 工程在 LangChain 1.0、Cursor 这类工具链里被反复强调的原因——Agent 不再是一个 Demo而是一套需要设计、测试、监控、兜底的系统。这篇文章会围绕这条学习路径展开先讲清楚 LangChain V1.0 到底变了什么再拆解 Harness 工程在 Agent 开发里充当什么角色然后是智能体工具怎么设计、怎么注册、怎么调用最后用一个 TextToSQL 项目走通“从库表结构到可执行 SQL”的完整链路。你还会看到本地模型部署、API 服务封装、批量任务评估和问题排查的实操思路。如果你正准备从传统后端或算法岗转大模型应用开发或者已经在做 Agent 但觉得效果不稳定、代码不可维护这篇内容建议收藏。1. 核心能力速览在展开技术细节之前先把这条全栈路线涉及的核心内容整理成一张表。它决定了你学什么、用什么、项目怎么做也直接对应了大模型 Agent 开发岗的实际技能要求。主题解决什么问题关键技术点落地形态LangChain V1.0大模型应用的编排与标准化新版 Chat Models、工具调用接口、LangGraph 作为复杂 Agent 运行时Agent 编排、RAG 管道、API 接入Harness 工程Agent 从“能跑”到“可靠”状态管理、重试、检查点、护栏、测试评估Cursor、Claude Code、企业级 Agent 平台智能体工具让模型具备调用外部能力函数调用、工具 Schema、参数校验、错误恢复查数据库、调 API、操作文件系统TextToSQL 项目NL2SQL 业务落地Schema 注入、Few-shot、SQL 执行、结果评估报表查询、数据分析助手、内部 BI从这条链路能看出来真正的 Agent 全栈开发不只是“调一个模型”而是三层能力底层是模型接入能力包括云端 API 和本地部署。中间层是框架与工程化解决编排、状态、重试、可观测性。上层是业务项目比如 TextToSQL、RAG 问答、自动化脚本把能力变成可用产品。2. 这门课适合谁解决什么问题大模型 Agent 开发的学习路径和传统 Web 后端有很多相通的地方但也有本质差异。传统开发是“代码逻辑确定”Agent 开发是“模型行为不确定”所以工程化思路完全不同。适合学这套内容的人主要有三类后端工程师已经掌握 Python、API 开发、数据库操作想快速切入大模型应用开发。算法工程师熟悉模型和 Prompt但对工程架构、服务封装、批处理不熟需要补齐工程短板。独立开发者与 AI 产品经理想用最低成本搭出可演示、可评估的 Agent 项目并真正上线给用户使用。这套课程对应的核心问题有三个第一LangChain 到底怎么用才不是“玩具代码”。网上大量教程还在用旧的 SequentialChain、LLMChainLangChain V1.0 已经把这些旧的抽象大幅简化。学完能知道新版本推荐哪些 API、哪些已经废弃。第二Agent 怎么做到可控、可观测、可恢复。这是 Harness 工程要回答的。真正的 Agent 项目不会只跑一次就成功你需要设计重试逻辑、错误注入、状态持久化、人机确认机制。第三TextToSQL 怎么做到“看起来能用实际也能用”。很多演示项目只能处理一条简单查询换个问法就崩。要落地需要处理表结构注入、列名模糊匹配、SQL 安全校验、多轮对话上下文维护等问题。使用边界也要提前说清楚这套内容偏应用开发不是大模型预训练或微调方向。微调会涉及但不是主线。本地部署需要一定硬件条件纯 CPU 也能跑小模型但效果和速度受限。TextToSQL 涉及数据库操作必须严格控制权限不能在未经授权的生产库上直接执行模型生成的 SQL。3. 环境准备与前置条件3.1 操作系统与语言版本从当前主流实践看推荐使用 Linux 或 macOS 做开发Windows 也可以但遇到依赖编译问题时会更麻烦。Python 版本建议 3.10 到 3.12部分依赖在老版本 Python 上会有兼容问题。如果你本机没有 Python建议直接用 Conda 或 uv 管理环境避免污染系统 Python。# 使用 conda 创建独立环境Python 3.11 是比较稳妥的选择 conda create -n agent-course python3.11 -y conda activate agent-course3.2 LangChain 安装LangChain V1.0 的安装方式和之前有一些差异。旧版本常把langchain、langchain-openai、langchain-community混着装V1.0 更强调按需引入核心包和集成包分得很清楚。# 安装 LangChain 核心包 pip install langchain # 按模型供应商安装集成包任选其一 pip install langchain-openai pip install langchain-anthropic pip install langchain-ollama # 如果用 LangGraph 做复杂 Agent 编排 pip install langgraph从 LangChain V1.0 开始官方把很多能力收敛到核心 API 中langchain-community里的部分工具可能需要额外安装。具体以当前官方文档为准。3.3 模型接入方式整个课程的代码跑通有两种模型接入方式方式一云端 API。使用 OpenAI 兼容接口。需要准备 API Key并配置环境变量。export OPENAI_API_KEYsk-xxxx方式二本地模型。使用 Ollama 部署开源模型然后通过 LangChain 的 Ollama 集成访问。# 安装并启动 Ollama 后拉取模型例如 qwen2.5 系列 ollama pull qwen2.5:14b本地部署的优势是数据不出内网、没有 API 费用适合企业敏感场景劣势是显存要求高14B 模型建议至少 16GB 显存。如果显存不够可以考虑 7B 或 8B 模型效果会有一定下降。实际占用需以本机推理参数为准。3.4 数据库环境TextToSQL 项目需要准备一个测试数据库。建议用 SQLite 起步没有额外服务适合学习业务化之后再迁移到 MySQL 或 PostgreSQL。pip install sqlite3 # Python 内置无需额外安装更稳妥的做法是准备一个 MySQL 8.x 或 PostgreSQL 实例创建只读账号这样在执行模型生成的 SQL 时能降低误操作风险。4. LangChain V1.0从链式调用到 Agent 编排4.1 V1.0 最大的变化是什么很多关注 LangChain 的人会问一个问题LangChain 和 LangGraph 到底有什么区别简单理解LangChain 负责“组件标准化”比如模型封装、Prompt 模板、输出解析、工具定义。LangGraph 负责“流程编排”它把 Agent 的每一步设计成图上的节点状态在有向图中流转支持条件分支、循环、人工确认、持久化。LangChain V1.0 的核心变化就是把这两个东西的关系理顺了。旧版本里复杂且容易出错的 AgentExecutor、Plan-and-Execute、ToolAgent 等抽象在 V1.0 中逐渐被 LangGraph 构建的运行时替代。官方推荐的复杂 Agent 开发方式基本是“用 LangChain 定义组件用 LangGraph 定义流程”。4.2 新版 Chat Model 调用LangChain V1.0 的模型调用接口更统一。下面是一个基础示例先跑通再说复杂的。from langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o-mini, temperature0.2, ) response llm.invoke(用一句话解释什么是 Agent) print(response.content)如果使用本地模型只需要换成 Ollama 集成。from langchain_ollama import ChatOllama llm ChatOllama( modelqwen2.5:14b, temperature0.2, ) response llm.invoke(用一句话解释什么是 TextToSQL) print(response.content)从 V1.0 起Chat Models 的.invoke()返回的是一个 AIMessage 对象既包含文本内容也可能包含工具调用这为后面的 Agent 工具设计打好了基础。4.3 LangGraph 的基本用法在 LangGraph 里一个 Agent 的最小结构是Agent 节点 工具节点 条件边。下面用一个简化示例展示“ReAct 循环”的核心逻辑。from langgraph.graph import StateGraph, START, END from typing import TypedDict, Annotated class AgentState(TypedDict): messages: Annotated[list, add_messages] def call_model(state: AgentState): response llm.invoke(state[messages]) return {messages: [response]} def call_tools(state: AgentState): # 在这里根据 model 返回的 tool_calls 执行工具 return {messages: [tool_msg]} graph StateGraph(AgentState) graph.add_node(agent, call_model) graph.add_node(tools, call_tools) graph.add_edge(START, agent) graph.add_conditional_edges(agent, route_after_model) graph.add_edge(tools, agent)这段代码省略了部分细节但结构已经能说明问题LangGraph 不像旧版 AgentExecutor 那样黑盒执行每一步都可以被观察、被拦截、被修改。这种“显式图结构”就是后面 Harness 工程的基础。5. Harness 工程让 Agent 从“能跑”到“可靠”5.1 什么是 Harness 工程Harness 这个词直译是“马具、安全背带”在 Agent 工程里可以理解为“控制模型执行的外部骨架”。模型本身只负责预测下一个 TokenAgent 要完成一个目标需要外部代码把下面这些事情管起来当前状态是什么、已经执行到哪一步哪些工具可用、参数怎么传模型调用失败后怎么重试结果不符合要求时怎么纠正整个链路怎么记录、怎么审计、怎么评估这一整套“模型之外的工程机制”就是 Harness 工程。Cursor 的 Agent 能连续处理多文件改动Claude Code 能稳定执行多步骤任务背后都有一层非常扎实的 Harness 在做控制。换句话说Harness 是“Agent 的骨架/脚手架”而 Agent 是“模型 工具 目标”的组合。5.2 Harness 工程的核心模块从实际项目拆解一个可靠的 Agent Harness 至少包含以下模块模块作用落地做法状态管理记录对话、步骤、工具结果LangGraph 的 StateRedis 持久化重试机制处理模型超时、工具异常按任务类型设置最大重试次数检查点崩溃后可恢复每步写入 Checkpointresume 重新加载护栏防止模型越权或输出危险内容工具白名单、SQL 只读校验、敏感词过滤测试与评估验证 Agent 是否达到业务标准构建回归测试集记录通过率可观测性定位问题链路日志、Trace、Token 用量统计5.3 为什么 Agent 项目需要 Harness只写 Prompt 和 Chain 的 Agent最常见的现象是同一个问题跑几次结果不稳定工具调用偶尔失败长流程跑到一半就卡死出了问题不知道是模型的问题还是代码的问题。Harness 工程化之后这些问题会有明确答案失败被捕获重试策略生效。状态可以持久化进程重启后能从断点继续。每一步的输入输出都有日志可以回放。评估集通过率达到目标后再发布。这也是为什么现在大模型 Agent 开发的招聘需求里越来越强调工程化能力。Harness 工程的本质就是“把不稳定的模型行为用稳定的工程机制包起来”。6. 智能体工具设计工具注册与函数调用6.1 工具调用基础Agent 要操作外部系统不能只靠模型背书必须把能力封装成“工具”让模型在需要时自动选择并传参调用。LangChain V1.0 推荐的工具定义方式非常简洁直接用装饰器即可。from langchain_core.tools import tool tool def get_weather(city: str) - str: 查询指定城市的天气情况参数 city 为城市名称例如 Beijing。 # 这里可以接入真实天气 API return f{city} 今天晴气温 24 度。定义完成后用 Tools 参数传给 Chat Model模型就会在回答前先判断是否需要调用这个工具。from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0) llm_with_tools llm.bind_tools([get_weather]) response llm_with_tools.invoke(北京今天天气怎么样) # 响应中包含 tool_calls表示模型要调用 get_weather参数为 {city: Beijing} print(response.tool_calls)6.2 工具执行的完整链路拿到 tool_calls 后Agent 不会自动执行工具需要业务代码把“调用请求”分发到具体函数再把执行结果返回给模型。from langchain_core.messages import ToolMessage def execute_tool_calls(tool_calls): results [] for call in tool_calls: tool_name call[name] tool_args call[args] if tool_name get_weather: result get_weather.invoke(tool_args) else: result 未知工具 results.append({ call_id: call[id], result: result, }) return results这种“模型生成意图 - 程序执行动作 - 结果回填模型”的循环是 Agent 的核心运行模式。面试里常问的“Agent 与普通 Chatbot 的区别”本质就在这里。6.3 工具设计规范工具不是随便定义就能用好实际项目中容易踩几个坑工具名和描述要写清楚。模型选择工具时主要靠描述理解描述含糊会导致选错工具。参数要收窄。能用枚举就用枚举能让模型少猜就少猜。要处理异常。工具内部失败时不要直接抛异常中断整个 Agent而是返回一段错误信息让模型尝试换一种方式解决。不要给模型不必要的工具。工具越多选择越难推理越慢。tool def execute_sql(query: str) - str: 执行只读 SQL 查询并返回查询结果。只允许 SELECT 语句。 参数 query 为完整 SQL。 if not query.strip().upper().startswith(SELECT): return 错误仅支持 SELECT 查询 # 连接到只读数据库执行查询 return run_readonly_query(query)这个例子很典型安全校验放在工具入口而不是模型输出之后才拦。这就是 Harness 工程中“护栏”的最简版本。7. TextToSQL 项目落地从 Schema 到可执行 SQL7.1 项目目标TextToSQL 的目标是用户输入自然语言Agent 输出可执行的 SQL并返回查询结果。比如“查一下 2025 年 1 月销售额最高的 5 个城市”系统要能自动生成 SQL执行后返回结果。这个项目能完整覆盖 Agent 开发的核心知识点模型接入与 Prompt 设计Schema 注入与 Few-shot工具调用与 SQL 执行错误恢复与多轮对话批量评估与效果量化7.2 系统 Prompt 与 Schema 注入TextToSQL 做得好不好第一块拼图是“让模型理解数据库结构”。常见做法是把系统 Prompt 和数据字典一起传给模型。schema_info 表名: sales 字段: - id: 主键 - city: 城市名称 - amount: 销售额 - order_date: 下单日期 表名: users 字段: - id: 主键 - name: 用户姓名 - city: 所属城市 system_prompt f 你是一个专业的数据库查询助手。请把用户问题转换为 SQL 查询。 严格要求 1. 只能使用以下表结构中的表和字段。 2. 只能输出 SQL 和必要说明不要输出额外内容。 3. SQL 必须是只读 SELECT 语句。 数据库结构如下 {schema_info} 这里的关键不是把整个数据库全部塞进 Prompt而是只注入当前任务需要的那一部分表。表太多会超过上下文窗口也会增加模型的选择难度。生产环境中可以先用关键词检索从元数据表里召回相关表再注入 Prompt。7.3 让模型“先想再写”推荐在 Prompt 中要求模型分两步先写执行计划再生成 SQL。这样能显著降低复杂查询的出错率也让调试更简单。prompt f 用户问题{question} 请按以下格式回答 1. 分析用户需要查询哪些字段、哪些表、哪些条件 2. SQL生成的 SQL 语句 如果使用 ReAct 思路可以让模型先列出候选表和候选字段再调用一个“工具”去查询表结构最后生成 SQL。这种方式适合表结构非常多的业务系统。7.4 多轮对话与查询条件补全TextToSQL 项目的难点之一是“问题本身信息不全”。比如用户说“帮我看看上周的销售情况”上周的具体日期不是模型能凭空推出来的。靠谱的做法是识别缺失的查询条件。反问用户。如果信息充分再生成 SQL。from langchain_core.messages import AIMessage if 上周 in question and 具体日期 not in context: follow_up 请问是指自然周还是最近 7 天我可以按不同口径查询。 return AIMessage(contentfollow_up)这里体现了“引导用户补充信息”比“硬猜条件”更可靠。生产级 TextToSQL 系统一定包含这种交互式澄清机制而不是一次性问答。7.5 SQL 执行与结果回传TextToSQL 的 Agent 同样遵循“模型生成意图 - 工具执行 - 结果回填”的循环。SQL 执行工具需要加上两层护栏只读检查和超时控制。tool def query_database(sql: str) - str: 执行只读查询并返回结果只允许 SELECT。 import sqlite3 if not sql.strip().lower().startswith(select): return 错误只能执行 SELECT 查询 conn sqlite3.connect(test.db) try: cursor conn.execute(sql) rows cursor.fetchmany(50) return \n.join([str(row) for row in rows]) except Exception as e: return fSQL 执行失败: {e} finally: conn.close()这里使用的是 SQLite 示例业务落地时需要换成 MySQL/PostgreSQL并注意连接复用、资源释放、并发限制和只读账号。8. 接口服务与批量评估8.1 把 Agent 封装成 APIAgent 写完之后要能被前端调用就必须封装成 HTTP 接口。使用 FastAPI 是常见的方案。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str session_id: str default app.post(/text2sql) def text_to_sql(req: QueryRequest): result agent_chain.invoke({question: req.question}) return { sql: result[sql], rows: result[rows], answer: result[answer] } # 启动服务 # uvicorn main:app --host 0.0.0.0 --port 8000接口设计上要注意三点所有参数做大小限制例如 question 最大长度 500。session 隔离避免多用户之间的对话上下文互相污染。记录每次请求的 SQL、耗时、Token 用量方便后续评估。8.2 批量任务用评估集验证效果TextToSQL 项目能不能上线取决于准确率。这就需要构建批量测试集。[ { question: 2025年1月销售额最高的城市是哪个, expected_sql: SELECT city FROM sales WHERE order_date 2025-01-01 AND order_date 2025-02-01 ORDER BY amount DESC LIMIT 1 }, { question: 统计每个城市的用户数, expected_sql: SELECT city, COUNT(*) FROM users GROUP BY city } ]然后写一个批量执行脚本对每个问题生成 SQL并做两类评估语法是否合法、结果是否与正确答案一致。import json from text2sql import agent_chain with open(eval_set.jsonl, encodingutf-8) as f: cases [json.loads(line) for line in f] total len(cases) pass_count 0 for case in cases: result agent_chain.invoke({question: case[question]}) is_pass result[rows] case[expected_rows] if is_pass: pass_count 1 else: print(f失败问题: {case[question]}) print(f生成 SQL: {result[sql]}) print(f通过率: {pass_count / total:.2%})这里建议把“expected_rows”设置成具体查询结果而不是只比 SQL 字符串因为同一个问题可以有多种等价 SQL 写法。8.3 批量任务的工程化真实业务的批量任务不会这么简单还要考虑多线程或异步执行提高评估效率。结果落盘保存为 JSONL方便回溯。失败重试。有些失败是模型临时超时重试一次可能就成功。按模型、按 Prompt 版本对比准确率迭代优化。import concurrent.futures with concurrent.futures.ThreadPoolExecutor(max_workers4) as executor: future_map {executor.submit(agent_chain.invoke, {question: c[question]}): c for c in cases} for future in concurrent.futures.as_completed(future_map): case future_map[future] try: result future.result(timeout60) # 记录结果 except Exception as e: # 记录失败原因 pass9. 性能观察与质量评估9.1 延迟与 Token 消耗Agent 项目的延迟不是单次模型调用的延迟而是整个循环的延迟。影响延迟的因素有模型大小和推理设备。工具数量。工具越多模型推理时需处理的 schema 越长。是否使用多轮循环。ReAct 步骤越多延迟越高。上下文长度。历史消息、Schema、工具描述都会增加输入 Token。在 TextToSQL 场景可以先量化几个指标单次生成 SQL 的耗时。平均需要几轮工具调用才能完成查询。每个问题平均消耗多少 Token。这些数据出来之后就能判断“换小模型还是缩短 Prompt”的优化方向。9.2 模型大小与效果取舍从当前开源模型生态看TextToSQL 对模型能力的要求偏高7B 到 8B 模型能处理简单单表查询复杂多表关联容易出错。14B 到 32B 模型在 SQL 生成场景表现明显更好但显存要求也更高。如果使用云端大模型 API效果通常最好但存在数据出域和数据合规问题。所以我给这个项目的建议是先用云 API 跑通完整链路验证业务价值再评估是否用本地模型替换。不要一上来就死磕本地部署容易卡在环境上。9.3 如何观察资源占用本地部署时观察资源占用的工具nvidia-smi看显存。ollama ps看当前加载的模型。htop看内存和 CPU。启动本地模型后观察几个时间段模型加载时、首次推理时、连续多轮推理时显存占用通常是不同的。批量任务长时间运行时还要关注显存是否持续增长排查内存泄漏。10. 常见问题与排查方法下面这些问题是 Agent 开发和 TextToSQL 项目中出现频率最高的整理成排查表可以直接对照处理。问题现象可能原因排查方式解决方案模型不调用工具工具描述不清、模型能力弱打印 tool_calls 查看优化工具描述减少工具数量工具参数格式错误模型生成的 JSON 不符合 Schema检查报错日志在工具入口增加参数解析和容错SQL 生成总是少 WHERE 条件上下文缺失、模型理解错误对比多轮输出的差异在 Prompt 中强调条件提取步骤SQL 执行报错表名/字段名写错打印生成的 SQL注入准确 Schema增加表名校正执行的 SQL 不是只读护栏不生效检查工具入口逻辑在工具入口强制校验 SELECT 开头Agent 循环停不下来工具结果无法让模型收敛查看循环次数设置最大迭代次数超过后强制结束批量评估通过率低模型能力不足或测试集有歧义抽样分析失败案例换更大模型或优化 Few-shot 示例本地模型显存不足模型太大或上下文过长查看 nvidia-smi换小模型或缩短注入的 Schema接口并发后响应变慢推理服务无并发控制查看 CPU/GPU 使用率增加队列、限制并发数进程启动后端口被占用上次进程未退出查看端口占用kill 掉残留进程或更换端口如果在 LangGraph 中遇到“agent execution terminated due to error”这类错误先不要慌。打开日志看终止在哪一步是模型调用失败、工具执行失败还是循环次数达到上限。这个问题大多数情况是某个工具抛了未捕获异常解决办法就是在工具函数内部全部接住异常并返回可读的错误信息。11. 最佳实践与学习建议11.1 从最小闭环开始不要一上来就搭一个超复杂的多工具 Agent。建议先把这条路走通定义 1 个工具。让模型成功调用一次。加入第 2 个工具。加入重试和错误处理。最后再做多轮和状态持久化。每一步都有明确的验证标准出了问题知道改哪里。11.2 维护一套评估集TextToSQL 项目最重要的资产不是代码而是评估集。建议把日常测试中所有失败过的、边界性的问题都沉淀到 JSONL 文件里。每次修改 Prompt、切换模型、优化 Schema 注入方式都跑一遍评估集用通过率决定要不要上线。{question: 没有城市字段的查询模型不应凭空生成 city 字段, expected_error: true}这种“负样本”对 SQL 生成的稳定性同样重要。11.3 安全合规是底线涉及数据库的 Agent一定要遵守几条红线只读账号数据库账号只授予 SELECT 权限。超时限制SQL 执行超时自动终止。行数限制限制返回行数避免大表全量扫描。审计日志记录每次生成的 SQL 和执行时间。内容审核如果 Agent 面向外部用户还要考虑生成内容的合规过滤。如果项目涉及人脸、声音、隐私数据或版权素材必须在授权范围内使用并在发布前完成合规评估。这部分没有捷径。11.4 LangChain 和 LangGraph 怎么学结合最近社区常见的问题这里多说一点学习顺序先用 LangChain 把“组件”搞清楚模型、Prompt、工具、输出解析。再学 LangGraph 的“图”节点、边、状态、条件路由。最后用 TextToSQL 或 RAG 项目串联所有知识点。LangChain 和 LangGraph 不是二选一而是互补关系。LangChain 管“零件”LangGraph 管“流水线”。面试如果被问到区别可以按这个思路回答再结合自己的项目讲清楚哪里用了 LangChain、哪里用了 LangGraph。12. 总结与下一步大模型 Agent 开发的完整链路本质上是“框架 工程化 业务项目”三件事叠加。LangChain V1.0 提供了组件标准LangGraph 提供了可控的运行时Harness 工程解决了可靠性问题TextToSQL 则是把这一切落到真实业务中的代表性项目。这篇内容里最值得先动手验证的是用 LangChain 定义一个工具把工具绑定到模型上跑通一次完整的“模型生成工具调用 - 程序执行 - 结果回填”循环。这一步通了后续的 Agent 编排、Harness 设计、TextToSQL 改造才有基础。最容易踩的坑也提前说第一工具没有异常处理Agent 跑到一半就崩第二TextToSQL 没有只读护栏存在数据误操作风险第三没有评估集根本无法判断效果是变好还是变坏。下一步可以继续扩展的方向首先是 RAG把企业私有文档接入 Agent让模型具备“基于资料回答”的能力然后是更复杂的多 Agent 协作比如一个 Agent 负责查数、一个 Agent 负责写报告、一个 Agent 做质检通过 LangGraph 串联起来。硬件条件允许的话可以用 Ollama 部署本地模型跑通相同链路对比本地模型和云端 API 在 SQL 生成场景的准确率和延迟差异这套对比数据在面试和项目汇报中都会很有说服力。