1. 林俊旸创业为什么值得开发者关注林俊旸官宣创业公司 Pragmatik Labs 的消息在大模型圈子里引发了不小的讨论。很多人第一反应是“又一个 DeepSeek 核心成员离开”但如果只停留在八卦层面就浪费了这个事件对技术从业者的真正价值。这件事值得关注的点不是“谁离开了哪家公司”而是他给出的创业方向AI Agent。林俊旸本人的判断是Agent 是现在 AI Labs 的最后一块拼图。这句话信息量很大。它意味着在大模型基础能力已经足够强的今天真正决定 AI 产品能不能落地的关键已经从前沿模型的参数竞赛转移到了“怎么让模型在真实工作流里稳定地完成任务”这条工程赛道上。对于普通开发者来说这可能是未来两到三年最值得投入的技术方向之一。因为 Agent 开发的门槛不在数学和论文里而在工程实践里怎么设计规划流程、怎么管理记忆、怎么让模型安全地调用外部工具。这些能力恰恰是应用层开发者可以积累的。这篇文章会从林俊旸创业事件切入讲清楚四个层面的问题Pragmatik Labs 做的是哪个方向的技术、AI Agent 到底和普通 AI 应用有什么本质区别、Agent 系统的核心技术栈怎么拆解、以及普通开发者现在可以做什么来提前卡位。如果你正在做 LLM 应用开发或者准备进入这个方向这篇文章会给你一条相对完整的认知框架和实操起点。2. Pragmatik Labs 在做什么AI Agent 赛道的基本盘按照公开信息Pragmatik Labs 是一家专注 AI Agent 的初创公司。从公司名字里的 Pragmatik 可以读出一些信号pragmatic 意为“务实的、实用主义的”。这个命名基本代表了团队的技术路线判断——不做通用大模型而是做能真正解决实际问题的智能体应用。这个选择背后有一个行业背景2025 年之后大模型基础能力的同质化程度快速上升。各家模型在通用对话、代码生成、逻辑推理上的差距在缩小但模型“能不能自主完成一个多步骤任务”的差距依然很大。而这个差距恰恰不是靠堆参数就能解决的它需要工程体系来补。林俊旸此前在 DeepSeek 的工作经历让他对模型的“上限”和“下限”都有非常具体的体感。他参与过 DeepSeek-V2、DeepSeek-V3、DeepSeek-R1 等模型的建设这些模型在推理能力上已经把大模型的“可能性”拉到了很高的位置。但真实场景里的问题从来不是“模型能不能写出正确答案”而是“模型在一个包含干扰信息、多轮交互、环境反馈的工作流里能不能一步步走到终点”。这恰恰是 Agent 要解决的事。从赛道选择来看Pragmatik Labs 走的是“应用层智能体”路线而不是“基础模型”路线。这个判断和当前产业环境是一致的基础模型的训练成本动辄千万美元起步而且头部玩家已经形成了事实上的资源壁垒。相比之下Agent 层的创新空间更大、迭代速度更快、对场景理解的要求更高也更适合小团队做出差异化。而且从人才配置看DeepSeek 系背景的团队做 Agent 有天然优势。Agent 的核心是让模型在复杂任务里保持稳定这需要对模型的推理模式、提示词行为、失败模式有深刻理解。一个做过模型训练的人来调 Agent对“模型为什么会在这一步出错”的感知会比只做过应用开发的人敏锐得多。所以 Pragmatik Labs 这步棋本质上是在做一个判断大模型的下半场比的不是谁的模型更聪明而是谁能让模型在真实业务流程里更可靠。3. AI Agent 与普通 AI 应用的本质区别很多人对 Agent 的理解停留在“能聊天的 AI 助手”这个认知需要修正。一个普通的 AI 应用比如智能客服、文章摘要工具、代码解释器本质上是“请求-响应”模式用户给一个输入模型给一个输出。整个过程是单轮的、被动的模型不持有目标也不对结果负责。Agent 则完全不同。它的核心特征是自主性给定一个目标Agent 自己拆解步骤、选择工具、执行操作、观察结果、调整策略直到任务完成或者明确失败。用一个对比来说明维度普通 AI 应用AI Agent交互方式单轮问答多轮自主决策是否持有目标不持有持有并拆解工具使用通常不调用主动选择并调用失败处理直接返回结果观察反馈后重试或换策略典型代表聊天机器人、内容生成器自动编程助手、智能数据分析员这个区别在真实场景里非常明显。比如“帮我分析这份销售数据并生成月度报告”这个任务。普通 AI 应用的做法是你把数据贴给它它生成一段分析文字。如果数据需要清洗、需要跨表关联、需要调用可视化库画图它就无能为力了。Agent 的做法是先理解任务目标拆解出“读取数据-检查数据质量-做统计分析-生成图表-撰写结论”几步然后依次调用文件读取工具、数据处理脚本、绘图函数、报告模板最后交出一份完整报告。中间任何一步失败它会根据错误信息调整策略重新尝试。这就是所谓的“最后一块拼图”的含义。模型负责“思考”Agent 框架负责“做事”。只有把这两者结合起来AI 才真正从“建议者”变成“执行者”。从这个角度看Agent 不是一个具体的技术点而是一整套工程范式。它把 AI 应用从“调用模型接口”升级为“编排一个智能工作流”。这场范式转移会重构现有的应用开发方式也会带来大量新的工程问题。4. Agent 系统的核心技术栈拆解要理解 Agent 开发先要拆解一个完整的 Agent 系统由哪些部分组成。从工程视角看一个可用的 Agent 系统至少包含五个模块基础模型层、规划层、工具层、记忆层、安全层。4.1 基础模型层Agent 的“大脑”基础模型层解决的是“理解与推理”的问题。Agent 依赖 LLM 来完成意图识别、方案生成、信息抽取、代码生成等认知任务。在模型选型上有两个关键指标推理能力和指令遵循能力。推理能力决定了 Agent 能不能处理复杂的多步任务指令遵循能力决定了 Agent 能不能严格按照预设格式输出结构化内容。实际开发中考虑到成本和使用体验常见做法是混合模型策略规划类任务用高推理能力的模型信息抽取和格式化输出这类简单任务用低成本的轻量模型。这个优化空间非常大也是 Agent 应用控制成本的主要手段之一。4.2 规划层Agent 的“决策中枢”规划层是 Agent 系统的核心它决定了一个 Agent 在拿到任务后应该按什么顺序执行哪些操作。目前最常用的规划模式是 ReActReasoning and Acting推理与行动。它的核心思想是让模型交替进行“思考-行动-观察”思考用户想让我分析销售数据我需要先找到数据文件。 行动调用 search_file参数为 {filename: sales_data.csv} 观察找到文件 /data/sales_data.csv 思考接下来需要读取这个文件并检查数据完整性。 行动调用 read_file参数为 {path: /data/sales_data.csv}这个循环会一直持续到任务完成。规划层的工程难点在于如何让模型少走弯路、如何在步骤太多时控制上下文长度、如何在规划出错时及时发现并纠正。简单任务可以用单次规划复杂任务则需要引入子 Agent 分解机制把一个大任务拆成多个子任务分别交给不同的子 Agent 执行最后汇总结果。4.3 工具层Agent 的“手脚”工具层是 Agent 具备执行能力的前提。没有工具层的 Agent 只能输出文字建议有了工具层Agent 才能查数据库、写文件、发请求、执行代码。工具层通常以函数调用的方式暴露给模型。每个工具需要定义清晰的名称、参数结构和功能描述模型根据这些元信息决定何时调用哪个工具。工具层的工程质量直接决定 Agent 的可靠程度。一个常见的坑是工具描述写得模糊导致模型在多个相似工具之间选错。比如“get_user_info”和“get_user_order”两个工具如果描述不区分使用场景模型很容易在查询用户信息时误调了订单查询接口。4.4 记忆层Agent 的“上下文”记忆层解决的是信息持久化的问题。模型本身没有记忆能力每轮对话的上下文窗口是有限的。Agent 需要在多轮任务中记住用户偏好、历史操作、中间结果这就需要一个独立于模型之外的记忆系统。记忆按时效可以分为短期记忆和长期记忆。短期记忆通常指当前任务内的上下文管理长期记忆则依赖于向量数据库或者结构化存储用于跨会话保留关键信息。短期记忆的难点在于管理上下文窗口。任务一长历史消息很快会把上下文塞满。常见的处理方式是对历史消息做摘要压缩、过滤已完成的中间步骤、只保留对后续决策有影响的关键信息。4.5 安全层Agent 的“刹车系统”安全层在 Agent 系统里不可省。因为 Agent 具备调用外部工具和自主决策的能力一旦失控风险比普通 AI 应用大得多。一个实际的例子Agent 在执行数据分析任务时如果被注入了一个错误的指令“删除数据库中的 user 表”具备工具调用能力的 Agent 有可能会直接执行。这在传统应用中是不可想象的因为传统程序的所有操作都是开发者预先写死的。因此安全层至少要包含三部分工具权限分级管理、操作确认机制、异常行为拦截。高风险操作必须经过人工确认低风险操作才可以自动执行。5. Agent 开发实战从零实现一个最小可用的 Agent前面讲了理论这部分用一个最小示例把 Agent 跑通。我们的目标是做一个“能查询天气并给出穿衣建议”的 Agent它有两个工具查询天气、计算温度差。通过这个例子你可以看到 Agent 的基本运行骨架。5.1 环境准备与依赖安装本示例使用 Python 3.9核心依赖是openai和一个轻量的 Agent 编排框架。pip install openai pip install langchain langchain-openai版本说明langchain的 API 变化较快如果你安装的版本和本文示例不完全一致以你实际安装版本的官方文档为准。本文重点演示整体思路不绑定特定版本。5.2 定义 Agent 的工具先定义两个工具函数。这里使用langchain_core.tools的tool装饰器它会自动把函数转换成模型可调用的工具接口。# 文件路径agent_tools.py from langchain_core.tools import tool from datetime import datetime tool def get_weather(city: str, date: str None) - str: 查询指定城市在指定日期的天气情况。 参数说明 - city城市名称例如“北京” - date日期格式为 YYYY-MM-DD不传则默认当天 if date is None: date datetime.now().strftime(%Y-%m-%d) # 这里接入真实天气 API本文使用模拟数据 weather_map { 北京: 晴气温 18-26 度微风, 上海: 小雨气温 22-28 度东南风 3 级, 广州: 雷阵雨气温 24-31 度南风 2 级, } return f{city} {date}{weather_map.get(city, 天气数据暂未覆盖)} tool def calc_temperature_diff(high: int, low: int) - int: 计算一天的最高温和最低温之间的温差用于判断是否需要增减衣物。 参数说明 - high最高温度摄氏度 - low最低温度摄氏度 return high - low这里的关键点是每个工具函数的 docstring 就是对模型的“使用说明书”。模型会读取这段描述决定什么时候调用这个工具、应该传什么参数。所以工具描述要写清楚功能边界和参数含义。5.3 构建 Agent 主程序接下来创建 Agent 主体把模型和工具绑定在一起进入循环执行模式。# 文件路径agent_main.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from agent_tools import get_weather, calc_temperature_diff # 初始化模型 llm ChatOpenAI( modelgpt-4o-mini, temperature0, # Agent 任务需要确定性输出temperature 推荐调低 ) # 收集工具 tools [get_weather, calc_temperature_diff] # 定义提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个实用的天气助手。请根据用户问题依次使用工具查询天气 并结合温度差给出穿衣建议。所有工具结果都要仔细阅读后再生成最终回答。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 创建 Agent agent create_tool_calling_agent(llm, tools, prompt) # 创建执行器 agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, # 打印运行日志便于观察 Agent 的决策过程 max_iterations5, # 限制最大迭代次数避免死循环 )5.4 运行 Agent 并观察决策过程在同一个目录下运行python agent_main.py不过上面的代码还没有加调用入口。为了便于测试可以再补一段# 文件路径agent_main.py续 if __name__ __main__: result agent_executor.invoke({ input: 北京今天天气怎么样适合穿什么 }) print(最终回答, result[output])预期输出大致如下 Entering new AgentExecutor chain... Invoking: get_weather with {city: 北京, date: 2025-06-18} 北京 2025-06-18晴气温 18-26 度微风 北京今天白天晴气温在 18 到 26 度之间温差不算大。 建议穿短袖外面加一件薄外套早晚偏凉注意保暖。这就是一个最小的 Agent 工作流。模型先识别出“需要查询天气”这个意图调用天气工具拿到结果后生成最终建议。5.5 把规划能力加进去温差计算场景如果用户问“北京今天温差大吗该怎么穿”Agent 需要连续调用两个工具先查天气再计算温差。通过verboseTrue的日志输出你可以清楚看到模型的多步规划过程Invoking: get_weather with {city: 北京} 北京晴气温 18-26 度微风 Invoking: calc_temperature_diff with {high: 26, low: 18} 8 北京今天温差 8 度早晚会比较凉。 建议采用“短袖 薄外套”的叠穿方案。这个例子虽然简单但已经展示了 Agent 的核心能力模型能根据工具返回的结果决定下一步动作。这就是 ReAct 模式的工程化实现。6. Agent 开发中最容易踩的坑Agent 开发表面上看只是“调 LLM 接口 定义几个函数”但真正投入项目后会发现坑比想象的多。这一节整理几类高频问题。6.1 工具描述不清晰模型乱选工具这是最常见的坑。模型选择工具的依据是函数名和描述文本如果描述有歧义模型就会选错。比如定义了get_sales_data和get_order_data如果描述里没有明确区分“销售汇总数据”和“订单明细数据”模型在用户问“上个月卖了多少”时可能选了只返回明细的接口导致最终结果完全错误。解决方法是工具描述里写清楚“这个工具适合什么场景”“不适合什么场景”并在参数名上做语义化比如把参数写成date_from、date_to而不是d1、d2。6.2 上下文被撑爆任务执行到一半失忆Agent 任务一长模型的历史消息会迅速占满上下文窗口。常见现象是任务执行到第 15 步时模型忘记了第 2 步已经做过的操作重复执行或者开始参考一些过期的中间结果导致结论错误。解决思路是引入上下文压缩机制。可以在每轮循环后把已完成的步骤摘要化只保留“当前目标-已完成动作-待执行动作”三个维度的信息。不要把所有历史消息都无脑塞给模型。6.3 没有最大迭代次数Agent 陷入死循环模型在遇到模棱两可的场景时可能会反复调用同一个工具输出相似的结果然后再次调用同一个工具形成死循环。这个问题在复杂任务里非常常见。代码层面要设置max_iterations运行层面要设置超时时间业务层面还要设计“兜底策略”超过指定次数后Agent 强制停止切换到人工接管流程。6.4 工具调用出错后没有重试机制工具不是永远可靠的。网络超时、接口限流、数据格式变化都会导致工具执行失败。如果不处理失败Agent 会把错误信息当作最终结果输出。更合理的做法是工具调用失败后把错误信息返回给模型让模型决定是重试还是换一种方式。同时要重试次数做限制避免无限重试。6.5 安全边界没设好高风险操作直接执行前面已经提到Agent 具备自动调用工具的能力所以同样也具备执行破坏性操作的风险。比如一个能操作数据库的 Agent如果在提示词注入下执行了DROP TABLE后果不堪设想。务实的做法是给工具分级。查询类工具可以自动执行写操作类工具必须人工确认删除类工具默认禁止。权限控制要放在代码层面而不是依赖模型的自觉。7. Agent 开发的常见问题排查表以下是 Agent 开发过程中出现频率较高的问题及对应排查思路建议直接收藏备用。问题现象可能原因排查方式解决方案模型始终不调用工具工具描述不明确或模型不支持 function calling检查模型 API 是否支持工具调用打印模型原始输出重写工具描述换成支持工具调用的模型工具参数传错工具参数 schema 定义与函数签名不一致检查 JSON Schema 里的类型和必填项统一类型声明必填参数不要给默认值Agent 反复调用同一工具上下文缺少变化模型无法判断进展观察 verbose 日志检查每轮工具返回值引入步骤摘要压缩无效上下文设置最大迭代次数执行到一半忘记目标上下文过长早期内容被截断检查输入的 token 数引入记忆压缩把已完成步骤摘要化工具抛出异常导致任务中断没有捕获工具执行异常查看异常堆栈在工具调用外层包装 try-except错误信息返回给模型最终回答不基于工具结果提示词没有强调“必须引用工具结果”检查 system prompt在提示词中增加约束要求模型基于工具输出作答同一次请求成本突然变高任务步数过多模型调用次数超出预期查看日志里的调用次数优化规划策略减少无效步骤使用便宜模型处理简单任务8. 从 Pragmatik Labs 看开发者该怎么布局 Agent 能力回到林俊旸创业这个话题。Pragmatik Labs 这类 Agent 创业公司出现对整个技术社区释放了一个明确信号Agent 不是 demo 层面的概念而是要进入真实业务场景的生产力工具。对于普通开发者可以从三个层面开始布局。8.1 掌握工具调用和提示词工程这是 Agent 开发的最低门槛。先把 function calling 的流程跑通理解模型是怎么根据工具描述生成结构化调用参数的。然后练习写高质量的工具描述和系统提示词这是 Agent 行为质量的分水岭。一个简单有效的练习把你日常工作中手动执行的 5 个任务拆解成“工具函数 模型决策”的结构尝试用 Agent 自动完成。8.2 动手搭一个多工具 Agent 项目不要只停留在看教程。找一个真实场景比如“自动整理会议纪要并发送邮件”“监控系统日志并生成告警报告”完整地做一个 Agent 项目。做项目时重点关心四个问题任务是怎么拆解的、工具之间的依赖怎么处理、上下文怎么管理、失败之后怎么恢复。这些问题只有在真实项目里才会遇到看教程永远学不会。8.3 建立安全和成本意识Agent 放大了模型的“自由”也放大了失控的风险。在生产环境中要给 Agent 的每一种工具定义权限边界给每一步操作设计审计日志给每一次调用设置成本上限。另外要养成一个习惯任何 Agent 项目上线前都要做“最坏情况推演”。如果模型自动执行了最危险的那个操作系统能不能拦住这个问题的答案决定了项目能不能上生产。9. 总结与后续学习方向林俊旸官宣创业 Pragmatik Labs这个消息本身会逐渐淡出热点但它指向的技术方向会在未来很长一段时间里持续影响大模型应用开发。这篇文章从事件切入讲清楚了几个核心问题Agent 和普通 AI 应用的本质区别是什么、一个完整 Agent 系统由哪些模块组成、最小可用的 Agent 代码怎么写、真实项目中会踩到哪些坑。如果你能照着第 5 节的例子跑通一个 Agent并且理解了第 6 节的坑你就已经比绝大多数停留在“调用 API 封装应用”阶段的开发者领先一步。后续可以沿着三个方向继续深入一是学习更复杂的 Agent 编排模式比如多 Agent 协作、分层规划二是研究记忆系统的工程实现包括向量检索和长期记忆管理三是关注 Agent 的评测体系因为“怎么衡量一个 Agent 的好坏”本身就是一个还没被解决的重大问题。正如 Pragmatik Labs 的命名所暗示的Agent 的方向会越来越务实。真正留下来的不是概念最炫的而是在真实业务里最稳的。 AI Agent开发全解析：从核心技术栈到工程实战
1. 林俊旸创业为什么值得开发者关注林俊旸官宣创业公司 Pragmatik Labs 的消息在大模型圈子里引发了不小的讨论。很多人第一反应是“又一个 DeepSeek 核心成员离开”但如果只停留在八卦层面就浪费了这个事件对技术从业者的真正价值。这件事值得关注的点不是“谁离开了哪家公司”而是他给出的创业方向AI Agent。林俊旸本人的判断是Agent 是现在 AI Labs 的最后一块拼图。这句话信息量很大。它意味着在大模型基础能力已经足够强的今天真正决定 AI 产品能不能落地的关键已经从前沿模型的参数竞赛转移到了“怎么让模型在真实工作流里稳定地完成任务”这条工程赛道上。对于普通开发者来说这可能是未来两到三年最值得投入的技术方向之一。因为 Agent 开发的门槛不在数学和论文里而在工程实践里怎么设计规划流程、怎么管理记忆、怎么让模型安全地调用外部工具。这些能力恰恰是应用层开发者可以积累的。这篇文章会从林俊旸创业事件切入讲清楚四个层面的问题Pragmatik Labs 做的是哪个方向的技术、AI Agent 到底和普通 AI 应用有什么本质区别、Agent 系统的核心技术栈怎么拆解、以及普通开发者现在可以做什么来提前卡位。如果你正在做 LLM 应用开发或者准备进入这个方向这篇文章会给你一条相对完整的认知框架和实操起点。2. Pragmatik Labs 在做什么AI Agent 赛道的基本盘按照公开信息Pragmatik Labs 是一家专注 AI Agent 的初创公司。从公司名字里的 Pragmatik 可以读出一些信号pragmatic 意为“务实的、实用主义的”。这个命名基本代表了团队的技术路线判断——不做通用大模型而是做能真正解决实际问题的智能体应用。这个选择背后有一个行业背景2025 年之后大模型基础能力的同质化程度快速上升。各家模型在通用对话、代码生成、逻辑推理上的差距在缩小但模型“能不能自主完成一个多步骤任务”的差距依然很大。而这个差距恰恰不是靠堆参数就能解决的它需要工程体系来补。林俊旸此前在 DeepSeek 的工作经历让他对模型的“上限”和“下限”都有非常具体的体感。他参与过 DeepSeek-V2、DeepSeek-V3、DeepSeek-R1 等模型的建设这些模型在推理能力上已经把大模型的“可能性”拉到了很高的位置。但真实场景里的问题从来不是“模型能不能写出正确答案”而是“模型在一个包含干扰信息、多轮交互、环境反馈的工作流里能不能一步步走到终点”。这恰恰是 Agent 要解决的事。从赛道选择来看Pragmatik Labs 走的是“应用层智能体”路线而不是“基础模型”路线。这个判断和当前产业环境是一致的基础模型的训练成本动辄千万美元起步而且头部玩家已经形成了事实上的资源壁垒。相比之下Agent 层的创新空间更大、迭代速度更快、对场景理解的要求更高也更适合小团队做出差异化。而且从人才配置看DeepSeek 系背景的团队做 Agent 有天然优势。Agent 的核心是让模型在复杂任务里保持稳定这需要对模型的推理模式、提示词行为、失败模式有深刻理解。一个做过模型训练的人来调 Agent对“模型为什么会在这一步出错”的感知会比只做过应用开发的人敏锐得多。所以 Pragmatik Labs 这步棋本质上是在做一个判断大模型的下半场比的不是谁的模型更聪明而是谁能让模型在真实业务流程里更可靠。3. AI Agent 与普通 AI 应用的本质区别很多人对 Agent 的理解停留在“能聊天的 AI 助手”这个认知需要修正。一个普通的 AI 应用比如智能客服、文章摘要工具、代码解释器本质上是“请求-响应”模式用户给一个输入模型给一个输出。整个过程是单轮的、被动的模型不持有目标也不对结果负责。Agent 则完全不同。它的核心特征是自主性给定一个目标Agent 自己拆解步骤、选择工具、执行操作、观察结果、调整策略直到任务完成或者明确失败。用一个对比来说明维度普通 AI 应用AI Agent交互方式单轮问答多轮自主决策是否持有目标不持有持有并拆解工具使用通常不调用主动选择并调用失败处理直接返回结果观察反馈后重试或换策略典型代表聊天机器人、内容生成器自动编程助手、智能数据分析员这个区别在真实场景里非常明显。比如“帮我分析这份销售数据并生成月度报告”这个任务。普通 AI 应用的做法是你把数据贴给它它生成一段分析文字。如果数据需要清洗、需要跨表关联、需要调用可视化库画图它就无能为力了。Agent 的做法是先理解任务目标拆解出“读取数据-检查数据质量-做统计分析-生成图表-撰写结论”几步然后依次调用文件读取工具、数据处理脚本、绘图函数、报告模板最后交出一份完整报告。中间任何一步失败它会根据错误信息调整策略重新尝试。这就是所谓的“最后一块拼图”的含义。模型负责“思考”Agent 框架负责“做事”。只有把这两者结合起来AI 才真正从“建议者”变成“执行者”。从这个角度看Agent 不是一个具体的技术点而是一整套工程范式。它把 AI 应用从“调用模型接口”升级为“编排一个智能工作流”。这场范式转移会重构现有的应用开发方式也会带来大量新的工程问题。4. Agent 系统的核心技术栈拆解要理解 Agent 开发先要拆解一个完整的 Agent 系统由哪些部分组成。从工程视角看一个可用的 Agent 系统至少包含五个模块基础模型层、规划层、工具层、记忆层、安全层。4.1 基础模型层Agent 的“大脑”基础模型层解决的是“理解与推理”的问题。Agent 依赖 LLM 来完成意图识别、方案生成、信息抽取、代码生成等认知任务。在模型选型上有两个关键指标推理能力和指令遵循能力。推理能力决定了 Agent 能不能处理复杂的多步任务指令遵循能力决定了 Agent 能不能严格按照预设格式输出结构化内容。实际开发中考虑到成本和使用体验常见做法是混合模型策略规划类任务用高推理能力的模型信息抽取和格式化输出这类简单任务用低成本的轻量模型。这个优化空间非常大也是 Agent 应用控制成本的主要手段之一。4.2 规划层Agent 的“决策中枢”规划层是 Agent 系统的核心它决定了一个 Agent 在拿到任务后应该按什么顺序执行哪些操作。目前最常用的规划模式是 ReActReasoning and Acting推理与行动。它的核心思想是让模型交替进行“思考-行动-观察”思考用户想让我分析销售数据我需要先找到数据文件。 行动调用 search_file参数为 {filename: sales_data.csv} 观察找到文件 /data/sales_data.csv 思考接下来需要读取这个文件并检查数据完整性。 行动调用 read_file参数为 {path: /data/sales_data.csv}这个循环会一直持续到任务完成。规划层的工程难点在于如何让模型少走弯路、如何在步骤太多时控制上下文长度、如何在规划出错时及时发现并纠正。简单任务可以用单次规划复杂任务则需要引入子 Agent 分解机制把一个大任务拆成多个子任务分别交给不同的子 Agent 执行最后汇总结果。4.3 工具层Agent 的“手脚”工具层是 Agent 具备执行能力的前提。没有工具层的 Agent 只能输出文字建议有了工具层Agent 才能查数据库、写文件、发请求、执行代码。工具层通常以函数调用的方式暴露给模型。每个工具需要定义清晰的名称、参数结构和功能描述模型根据这些元信息决定何时调用哪个工具。工具层的工程质量直接决定 Agent 的可靠程度。一个常见的坑是工具描述写得模糊导致模型在多个相似工具之间选错。比如“get_user_info”和“get_user_order”两个工具如果描述不区分使用场景模型很容易在查询用户信息时误调了订单查询接口。4.4 记忆层Agent 的“上下文”记忆层解决的是信息持久化的问题。模型本身没有记忆能力每轮对话的上下文窗口是有限的。Agent 需要在多轮任务中记住用户偏好、历史操作、中间结果这就需要一个独立于模型之外的记忆系统。记忆按时效可以分为短期记忆和长期记忆。短期记忆通常指当前任务内的上下文管理长期记忆则依赖于向量数据库或者结构化存储用于跨会话保留关键信息。短期记忆的难点在于管理上下文窗口。任务一长历史消息很快会把上下文塞满。常见的处理方式是对历史消息做摘要压缩、过滤已完成的中间步骤、只保留对后续决策有影响的关键信息。4.5 安全层Agent 的“刹车系统”安全层在 Agent 系统里不可省。因为 Agent 具备调用外部工具和自主决策的能力一旦失控风险比普通 AI 应用大得多。一个实际的例子Agent 在执行数据分析任务时如果被注入了一个错误的指令“删除数据库中的 user 表”具备工具调用能力的 Agent 有可能会直接执行。这在传统应用中是不可想象的因为传统程序的所有操作都是开发者预先写死的。因此安全层至少要包含三部分工具权限分级管理、操作确认机制、异常行为拦截。高风险操作必须经过人工确认低风险操作才可以自动执行。5. Agent 开发实战从零实现一个最小可用的 Agent前面讲了理论这部分用一个最小示例把 Agent 跑通。我们的目标是做一个“能查询天气并给出穿衣建议”的 Agent它有两个工具查询天气、计算温度差。通过这个例子你可以看到 Agent 的基本运行骨架。5.1 环境准备与依赖安装本示例使用 Python 3.9核心依赖是openai和一个轻量的 Agent 编排框架。pip install openai pip install langchain langchain-openai版本说明langchain的 API 变化较快如果你安装的版本和本文示例不完全一致以你实际安装版本的官方文档为准。本文重点演示整体思路不绑定特定版本。5.2 定义 Agent 的工具先定义两个工具函数。这里使用langchain_core.tools的tool装饰器它会自动把函数转换成模型可调用的工具接口。# 文件路径agent_tools.py from langchain_core.tools import tool from datetime import datetime tool def get_weather(city: str, date: str None) - str: 查询指定城市在指定日期的天气情况。 参数说明 - city城市名称例如“北京” - date日期格式为 YYYY-MM-DD不传则默认当天 if date is None: date datetime.now().strftime(%Y-%m-%d) # 这里接入真实天气 API本文使用模拟数据 weather_map { 北京: 晴气温 18-26 度微风, 上海: 小雨气温 22-28 度东南风 3 级, 广州: 雷阵雨气温 24-31 度南风 2 级, } return f{city} {date}{weather_map.get(city, 天气数据暂未覆盖)} tool def calc_temperature_diff(high: int, low: int) - int: 计算一天的最高温和最低温之间的温差用于判断是否需要增减衣物。 参数说明 - high最高温度摄氏度 - low最低温度摄氏度 return high - low这里的关键点是每个工具函数的 docstring 就是对模型的“使用说明书”。模型会读取这段描述决定什么时候调用这个工具、应该传什么参数。所以工具描述要写清楚功能边界和参数含义。5.3 构建 Agent 主程序接下来创建 Agent 主体把模型和工具绑定在一起进入循环执行模式。# 文件路径agent_main.py from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from agent_tools import get_weather, calc_temperature_diff # 初始化模型 llm ChatOpenAI( modelgpt-4o-mini, temperature0, # Agent 任务需要确定性输出temperature 推荐调低 ) # 收集工具 tools [get_weather, calc_temperature_diff] # 定义提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个实用的天气助手。请根据用户问题依次使用工具查询天气 并结合温度差给出穿衣建议。所有工具结果都要仔细阅读后再生成最终回答。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 创建 Agent agent create_tool_calling_agent(llm, tools, prompt) # 创建执行器 agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, # 打印运行日志便于观察 Agent 的决策过程 max_iterations5, # 限制最大迭代次数避免死循环 )5.4 运行 Agent 并观察决策过程在同一个目录下运行python agent_main.py不过上面的代码还没有加调用入口。为了便于测试可以再补一段# 文件路径agent_main.py续 if __name__ __main__: result agent_executor.invoke({ input: 北京今天天气怎么样适合穿什么 }) print(最终回答, result[output])预期输出大致如下 Entering new AgentExecutor chain... Invoking: get_weather with {city: 北京, date: 2025-06-18} 北京 2025-06-18晴气温 18-26 度微风 北京今天白天晴气温在 18 到 26 度之间温差不算大。 建议穿短袖外面加一件薄外套早晚偏凉注意保暖。这就是一个最小的 Agent 工作流。模型先识别出“需要查询天气”这个意图调用天气工具拿到结果后生成最终建议。5.5 把规划能力加进去温差计算场景如果用户问“北京今天温差大吗该怎么穿”Agent 需要连续调用两个工具先查天气再计算温差。通过verboseTrue的日志输出你可以清楚看到模型的多步规划过程Invoking: get_weather with {city: 北京} 北京晴气温 18-26 度微风 Invoking: calc_temperature_diff with {high: 26, low: 18} 8 北京今天温差 8 度早晚会比较凉。 建议采用“短袖 薄外套”的叠穿方案。这个例子虽然简单但已经展示了 Agent 的核心能力模型能根据工具返回的结果决定下一步动作。这就是 ReAct 模式的工程化实现。6. Agent 开发中最容易踩的坑Agent 开发表面上看只是“调 LLM 接口 定义几个函数”但真正投入项目后会发现坑比想象的多。这一节整理几类高频问题。6.1 工具描述不清晰模型乱选工具这是最常见的坑。模型选择工具的依据是函数名和描述文本如果描述有歧义模型就会选错。比如定义了get_sales_data和get_order_data如果描述里没有明确区分“销售汇总数据”和“订单明细数据”模型在用户问“上个月卖了多少”时可能选了只返回明细的接口导致最终结果完全错误。解决方法是工具描述里写清楚“这个工具适合什么场景”“不适合什么场景”并在参数名上做语义化比如把参数写成date_from、date_to而不是d1、d2。6.2 上下文被撑爆任务执行到一半失忆Agent 任务一长模型的历史消息会迅速占满上下文窗口。常见现象是任务执行到第 15 步时模型忘记了第 2 步已经做过的操作重复执行或者开始参考一些过期的中间结果导致结论错误。解决思路是引入上下文压缩机制。可以在每轮循环后把已完成的步骤摘要化只保留“当前目标-已完成动作-待执行动作”三个维度的信息。不要把所有历史消息都无脑塞给模型。6.3 没有最大迭代次数Agent 陷入死循环模型在遇到模棱两可的场景时可能会反复调用同一个工具输出相似的结果然后再次调用同一个工具形成死循环。这个问题在复杂任务里非常常见。代码层面要设置max_iterations运行层面要设置超时时间业务层面还要设计“兜底策略”超过指定次数后Agent 强制停止切换到人工接管流程。6.4 工具调用出错后没有重试机制工具不是永远可靠的。网络超时、接口限流、数据格式变化都会导致工具执行失败。如果不处理失败Agent 会把错误信息当作最终结果输出。更合理的做法是工具调用失败后把错误信息返回给模型让模型决定是重试还是换一种方式。同时要重试次数做限制避免无限重试。6.5 安全边界没设好高风险操作直接执行前面已经提到Agent 具备自动调用工具的能力所以同样也具备执行破坏性操作的风险。比如一个能操作数据库的 Agent如果在提示词注入下执行了DROP TABLE后果不堪设想。务实的做法是给工具分级。查询类工具可以自动执行写操作类工具必须人工确认删除类工具默认禁止。权限控制要放在代码层面而不是依赖模型的自觉。7. Agent 开发的常见问题排查表以下是 Agent 开发过程中出现频率较高的问题及对应排查思路建议直接收藏备用。问题现象可能原因排查方式解决方案模型始终不调用工具工具描述不明确或模型不支持 function calling检查模型 API 是否支持工具调用打印模型原始输出重写工具描述换成支持工具调用的模型工具参数传错工具参数 schema 定义与函数签名不一致检查 JSON Schema 里的类型和必填项统一类型声明必填参数不要给默认值Agent 反复调用同一工具上下文缺少变化模型无法判断进展观察 verbose 日志检查每轮工具返回值引入步骤摘要压缩无效上下文设置最大迭代次数执行到一半忘记目标上下文过长早期内容被截断检查输入的 token 数引入记忆压缩把已完成步骤摘要化工具抛出异常导致任务中断没有捕获工具执行异常查看异常堆栈在工具调用外层包装 try-except错误信息返回给模型最终回答不基于工具结果提示词没有强调“必须引用工具结果”检查 system prompt在提示词中增加约束要求模型基于工具输出作答同一次请求成本突然变高任务步数过多模型调用次数超出预期查看日志里的调用次数优化规划策略减少无效步骤使用便宜模型处理简单任务8. 从 Pragmatik Labs 看开发者该怎么布局 Agent 能力回到林俊旸创业这个话题。Pragmatik Labs 这类 Agent 创业公司出现对整个技术社区释放了一个明确信号Agent 不是 demo 层面的概念而是要进入真实业务场景的生产力工具。对于普通开发者可以从三个层面开始布局。8.1 掌握工具调用和提示词工程这是 Agent 开发的最低门槛。先把 function calling 的流程跑通理解模型是怎么根据工具描述生成结构化调用参数的。然后练习写高质量的工具描述和系统提示词这是 Agent 行为质量的分水岭。一个简单有效的练习把你日常工作中手动执行的 5 个任务拆解成“工具函数 模型决策”的结构尝试用 Agent 自动完成。8.2 动手搭一个多工具 Agent 项目不要只停留在看教程。找一个真实场景比如“自动整理会议纪要并发送邮件”“监控系统日志并生成告警报告”完整地做一个 Agent 项目。做项目时重点关心四个问题任务是怎么拆解的、工具之间的依赖怎么处理、上下文怎么管理、失败之后怎么恢复。这些问题只有在真实项目里才会遇到看教程永远学不会。8.3 建立安全和成本意识Agent 放大了模型的“自由”也放大了失控的风险。在生产环境中要给 Agent 的每一种工具定义权限边界给每一步操作设计审计日志给每一次调用设置成本上限。另外要养成一个习惯任何 Agent 项目上线前都要做“最坏情况推演”。如果模型自动执行了最危险的那个操作系统能不能拦住这个问题的答案决定了项目能不能上生产。9. 总结与后续学习方向林俊旸官宣创业 Pragmatik Labs这个消息本身会逐渐淡出热点但它指向的技术方向会在未来很长一段时间里持续影响大模型应用开发。这篇文章从事件切入讲清楚了几个核心问题Agent 和普通 AI 应用的本质区别是什么、一个完整 Agent 系统由哪些模块组成、最小可用的 Agent 代码怎么写、真实项目中会踩到哪些坑。如果你能照着第 5 节的例子跑通一个 Agent并且理解了第 6 节的坑你就已经比绝大多数停留在“调用 API 封装应用”阶段的开发者领先一步。后续可以沿着三个方向继续深入一是学习更复杂的 Agent 编排模式比如多 Agent 协作、分层规划二是研究记忆系统的工程实现包括向量检索和长期记忆管理三是关注 Agent 的评测体系因为“怎么衡量一个 Agent 的好坏”本身就是一个还没被解决的重大问题。正如 Pragmatik Labs 的命名所暗示的Agent 的方向会越来越务实。真正留下来的不是概念最炫的而是在真实业务里最稳的。