1. 从一份日报标题看 Agent 与 LLM 的真实技术水位看到Agent / LLM 技术精选日报这个标题很多人第一反应是又一个资讯聚合。但如果你真的在一线做 Agent 和 LLM 相关的东西就会明白这类日报的价值根本不在资讯两个字而在于它是一份技术水位的切片。2026 年这个时间点上Agent 和 LLM 这两个词已经被用烂了但真正能跑通、能上线、能扛住真实流量的项目和网上那些 demo 之间差距比想象中大得多。我自己从 2023 年开始折腾 LLM 应用从最早的 prompt 拼接到后来的 RAG再到现在的多 Agent 编排踩过的坑基本能写一本书。这份日报标题里藏着的信息量其实很大Agent 已经从一个概念验证阶段进入了工程化落地阶段LLM 也不再是单纯比谁参数大而是比谁的上下文管理、工具调用、记忆机制做得更扎实。热搜词里出现的agent execution terminated due to error、llm request failed: provider rejected the request schema or tool payload、codex无法发送消息显示更新agent沙盒这些全是真实生产环境里会撞上的问题不是实验室里的玩具。这篇文章我想做的事情很明确把这份日报标题背后涉及的核心技术点拆开讲清楚 Agent 和 LLM 在 2026 年这个节点上到底发展到什么程度哪些是真正值得投入的方向哪些是看起来热闹但实际落地困难的坑。适合谁看如果你正在做 Agent 开发、正在选 LLM 框架、正在纠结 RAG 和 wiki 知识库怎么选、或者单纯想搞清楚Agent 到底能干什么这篇应该能给你一些直接能用的判断依据。我不会堆砌概念每个点都会落到为什么这么选和实际怎么操作上。2. Agent 与 LLM 技术全景拆解2.1 Agent 到底是什么从会聊天到会干活的分界线很多人对 Agent 的理解还停留在能调用工具的 ChatGPT。这个理解不算错但太浅了。Agent 的本质区别在于自主性——它能在没有人类逐步指令的情况下自己决定下一步做什么。普通 LLM 调用是你问一句它答一句Agent 是你给一个目标它自己拆解、执行、检查、修正。这个区别听起来简单但工程上的复杂度差了一个数量级。普通 LLM 调用你只需要管好 prompt 和输出解析Agent 你要管的是任务规划、工具选择、执行监控、错误恢复、状态管理、记忆读写。热搜词里那个agent execution terminated due to error就是典型的 Agent 特有问题——普通 LLM 调用出错顶多返回个错误信息Agent 执行到一半挂了你得知道它挂在哪一步、之前的状态能不能恢复、要不要回滚。从架构上看一个能用的 Agent 至少包含这几个部分规划器Planner负责把目标拆成步骤执行器Executor负责调用工具记忆Memory负责存上下文和历史反思器Reflector负责检查结果对不对。这四块缺一个Agent 就只能做玩具。热搜里提到的a-memguard: a proactive defense framework for llm-based agent memory就是在解决记忆这块的安全问题——Agent 的记忆如果被污染整个决策链都会跑偏。2.2 LLM 在 Agent 里的角色不只是大脑更是翻译官很多人把 LLM 在 Agent 里的角色简单理解为大脑负责思考。这个比喻对了一半。LLM 在 Agent 里其实干两件事一是推理把模糊的目标翻译成具体的步骤二是接口转换把自然语言翻译成工具能理解的参数格式。第二件事经常被低估。热搜词里llm request failed: provider rejected the request schema or tool payload这个错误十有八九就是接口转换出了问题——LLM 生成的工具调用参数格式不对或者 schema 定义和实际不匹配。这个问题在早期 Agent 开发里特别常见因为不同 LLM 对 function calling 的支持程度不一样有的严格按 JSON Schema有的会自作主张加字段。所以选 LLM 的时候不能只看 benchmark 分数。open llm leaderboard上的排名参考价值有限真正要测的是这个模型在你的工具集上function calling 的成功率是多少。我自己的经验是同一个模型在不同工具 schema 下的表现能差 30% 以上。有些模型对嵌套参数支持好有些对枚举类型处理稳这些都得实测。2.3 知识库路线之争RAG、GraphRAG 还是 LLM Wiki热搜词里rag graphrag llm wiki 本体rag、llm wiki知识库、karpathy llm wiki这几个词放在一起说明知识库这块正在发生路线分化。传统 RAG 是切片-向量化-检索-拼接简单直接但有个致命问题它不理解知识之间的关系。你问这个药物的禁忌症RAG 能检索到相关段落但你问这个药物和那个药物能不能一起吃RAG 就抓瞎了因为它不知道两个药物之间的相互作用关系。GraphRAG 的思路是先把知识建成图节点是实体边是关系检索的时候沿着图走。这个方案对结构化程度高的领域特别有效比如医疗、法律、金融。但代价是构建成本高你得先做实体抽取和关系抽取这一步的准确率直接决定整个系统的上限。LLM Wiki 这个方向比较新Karpathy 提的那个思路核心是让 LLM 自己维护一个结构化的知识库而不是每次从原始文档里检索。这个方案的好处是知识经过 LLM 的消化一致性更好坏处是 LLM 会犯错错误会被固化到 wiki 里。热搜里llm ontology这个词说明大家开始关注本体论层面的建模这其实是知识库走向成熟的标志——从能检索到能推理。2.4 Agent 框架与编排为什么没有银弹agent框架与编排、agent架构、llm框架这几个词说明框架选型是当前的热点痛点。市面上框架很多LangChain、LlamaIndex、AutoGen、CrewAI还有各种自研的。我的判断是没有哪个框架能通吃所有场景。LangChain 生态最全但抽象层太多调试的时候一层套一层出问题很难定位。LlamaIndex 在 RAG 这块做得深但 Agent 编排相对弱。AutoGen 的多 Agent 对话机制设计得不错但生产环境的稳定性还需要打磨。CrewAI 的角色定义很直观适合快速搭原型但复杂流程控制会吃力。选框架的核心判断标准是你的 Agent 是单任务还是多任务是单 Agent 还是多 Agent需不需要人工介入。单任务单 Agent直接用原生 API 加一层薄封装就够了上框架反而是负担。多 Agent 协作才需要框架来管通信和状态同步。热搜里agent for beginner、agent开发学习路线这些词说明很多新手在找入门路径我的建议是先用原生 API 手写一个最简单的 ReAct Agent理解清楚循环逻辑再去看框架不然容易被框架的抽象绕晕。3. 核心细节解析与实操要点3.1 Agent 记忆机制为什么你的 Agent 聊三句就失忆Agent 记忆是当前最被低估的技术点。热搜里agent记忆单独成为一个词说明这是普遍痛点。Agent 的记忆分三层短期记忆当前对话的上下文、长期记忆跨会话的知识、工作记忆当前任务的中间状态。短期记忆的问题是好解决的就是上下文窗口管理。但这里有个坑不是把所有历史都塞进去就好。上下文越长LLM 的注意力越分散关键信息反而容易被淹没。我实测下来对话历史超过 20 轮之后检索式记忆比全量塞入效果好。具体做法是把历史对话做摘要只保留关键决策点和当前任务相关的部分。长期记忆的坑更深。很多方案是用向量数据库存历史对话检索的时候按相似度取。但相似度高的对话不一定对当前任务有用。比如用户上次问怎么退款这次问怎么改地址向量检索可能把退款那段翻出来但实际没用。更好的做法是按实体和意图做结构化存储退款记录归退款地址变更归地址变更检索的时候按意图路由。工作记忆是最容易出问题的。Agent 执行多步任务的时候中间状态如果没存好一步失败整个任务就得重来。热搜里agent execution terminated due to error很多时候就是工作记忆丢失导致的。我的做法是每一步执行完都把状态序列化存下来失败的时候可以从最近的检查点恢复而不是从头开始。提示记忆模块一定要做容量控制。我见过有项目把 Agent 的所有历史对话都存着跑了一个月数据库爆了。长期记忆要有淘汰策略低频的、过期的要定期清理。3.2 工具调用的稳定性schema 设计比模型选择更重要llm request failed: provider rejected the request schema or tool payload这个错误我踩过太多次了。根本原因通常是工具 schema 设计得不合理。几个实操要点第一参数类型要明确。不要用any或者object这种模糊类型LLM 生成参数的时候会瞎猜。每个参数都要有明确的 type、description、是否必填。第二枚举值要列全。如果一个参数只能是几个固定值一定要用 enum 列出来并且在 description 里解释每个值的含义。我见过有工具的参数是操作类型没列枚举LLM 生成了删除但实际只支持新增和修改直接报错。第三嵌套层级不要太深。超过三层的嵌套参数LLM 出错的概率急剧上升。如果业务上确实需要复杂结构拆成多个简单工具让 Agent 分步调用。第四错误信息要可读。工具执行失败返回的错误信息要能让 LLM 理解并修正。返回Error 500这种LLM 完全不知道怎么改。返回参数 start_date 格式错误应为 YYYY-MM-DD实际收到 2026/09/23LLM 下次就知道怎么改了。常见 schema 问题表现修复方式参数类型模糊LLM 生成字符串但需要数字明确 type加格式示例枚举未列全LLM 生成非法值用 enum 列全description 解释嵌套过深参数结构错误率高拆分为多个扁平工具错误信息模糊LLM 无法自我修正返回具体错误原因和期望格式必填项未标注LLM 漏传参数required 字段明确列出3.3 LLM 网关多模型切换的工程实践llm 网关这个词说明多模型管理已经成为刚需。原因很简单没有哪个模型在所有任务上都最好。推理任务可能这个模型强代码生成那个模型强成本敏感的场景又得用便宜的。LLM 网关就是解决这个问题的中间层。网关要干几件事路由根据任务类型选模型、降级主模型挂了切备用、限流控制成本和并发、日志记录每次调用的输入输出和耗时。这几件事里路由和降级是核心。路由策略我一般分三层按任务类型路由代码任务走代码模型对话任务走对话模型、按复杂度路由简单问题走小模型复杂问题走大模型、按成本路由非关键路径走便宜模型。降级策略要设好触发条件比如连续三次超时、错误率超过阈值自动切换。这里有个坑不同模型的 prompt 格式可能不一样。有的模型对 system prompt 敏感有的对 few-shot 示例敏感。网关如果只是简单转发效果会打折扣。好的网关应该支持 per-model 的 prompt 模板让每个模型都能用最适合它的格式。3.4 Agent 安全不只是别让它删库agent安全和a-memguard这两个词放在一起说明 Agent 安全已经从业余讨论进入学术研究阶段。Agent 安全和传统应用安全最大的区别是Agent 的行为是动态生成的你没法预先枚举所有可能的操作。传统应用你写死了用户只能查自己的订单Agent 你可能给它一个查询订单的工具它自己决定传什么参数。如果参数校验不严它可能查出别人的订单。所以 Agent 安全的第一道防线是工具层面的权限控制每个工具调用都要校验当前上下文有没有权限不能依赖 Agent 自己判断。第二道防线是操作审计。Agent 的每一步决策和工具调用都要记录出问题能追溯。特别是涉及写操作、删除操作、资金操作的要有二次确认机制。第三道防线是记忆隔离。a-memguard那篇论文的核心思想就是防止恶意内容污染 Agent 记忆。如果 Agent 的记忆可以被外部输入写入攻击者可以通过构造特定输入让 Agent 记住错误信息后续决策全部跑偏。做法是记忆写入要经过校验敏感信息要脱敏不同用户的记忆要隔离。注意Agent 的自主性和安全性是天然矛盾的。自主性越高越难控制。我的经验是高风险操作一定要加人工确认环节不要追求全自动。全自动的 Agent 在 demo 里很酷在生产环境里是定时炸弹。4. 实操过程与核心环节实现4.1 从零搭一个最小可用 Agent完整步骤这一节我直接给一套可以抄的流程。目标是一个能查数据库、能调 API、能记住上下文的 Agent。技术栈用 Python 原生 LLM API不依赖重框架方便理解底层逻辑。第一步定义工具集。工具用 JSON Schema 描述每个工具包含 name、description、parameters。description 要写清楚什么时候用这个工具不只是这个工具干什么。比如查询工具的描述应该是当用户询问订单状态、物流信息时使用而不是查询订单。tools [ { name: query_order, description: 当用户询问订单状态、物流进度、预计送达时间时调用此工具, parameters: { type: object, properties: { order_id: { type: string, description: 订单编号格式为 ORD 开头加 12 位数字 }, query_type: { type: string, enum: [status, logistics, eta], description: 查询类型status 查状态logistics 查物流eta 查预计送达 } }, required: [order_id, query_type] } } ]第二步实现 Agent 主循环。核心逻辑是把用户输入和工具定义发给 LLMLLM 返回要么是最终答案要么是工具调用请求。如果是工具调用执行工具把结果塞回上下文再发给 LLM循环直到得到最终答案或达到最大轮数。def run_agent(user_input, max_turns10): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ] for turn in range(max_turns): response call_llm(messages, toolstools) if response.has_tool_call: tool_result execute_tool( response.tool_name, response.tool_args ) messages.append(response.message) messages.append({ role: tool, content: json.dumps(tool_result) }) else: return response.content return 达到最大轮数任务未完成第三步加记忆。短期记忆就是 messages 列表但要控制长度。我的做法是超过 15 轮之后把最早的 5 轮做摘要替换成一条 summary 消息。长期记忆用 SQLite 存关键信息按 user_id 和 session_id 索引。第四步加错误处理。工具执行失败要区分类型参数错误让 LLM 重新生成参数、权限错误直接返回拒绝、系统错误重试或降级。参数错误要把具体哪里错了告诉 LLM让它修正。第五步加日志和监控。每次 LLM 调用的输入输出、每次工具调用的参数和结果、每轮循环的耗时全部记录。这些日志是后续优化的唯一依据。4.2 参数计算上下文窗口和成本怎么平衡Agent 的上下文消耗比普通对话大得多因为每一轮都要把工具定义、历史消息、工具结果全部带上。我算过一笔账一个 10 轮的工具调用任务上下文消耗大概是普通对话的 5 到 8 倍。具体计算方式假设工具定义 2000 tokensystem prompt 500 token每轮用户输入加 LLM 输出平均 300 token工具结果平均 500 token。10 轮下来总 token 消耗大约是 2000 500 10 × (300 500) 10500 token。如果每轮都把完整历史带上实际消耗会更高因为第 10 轮的时候前面 9 轮的历史都在上下文里。优化手段有几个工具定义按需加载不是所有任务都需要所有工具根据用户意图先筛选相关工具历史消息压缩超过一定轮数做摘要工具结果截断返回结果太长的话只保留关键字段。这几个手段组合用能把上下文消耗压到原来的 40% 左右。成本这块如果用的是按 token 计费的 API一个复杂 Agent 任务跑下来成本可能是普通对话的 10 倍以上。所以路由策略很重要简单任务走便宜模型复杂任务才走贵模型。我自己的经验是70% 的任务用中等模型就能搞定只有 30% 需要上大模型。4.3 部署与测试Agent 上线前必须过的几道关agent 部署 测试软件这个词说明部署和测试是当前痛点。Agent 的测试和传统软件测试完全不一样因为输出是不确定的。我的做法是分三层测试单元测试测工具。每个工具单独测输入各种边界值确保工具本身没问题。这层是确定性的可以用传统测试方法。集成测试测 Agent 循环。构造一批标准任务看 Agent 能不能正确调用工具、正确处理错误、正确结束。这层要关注的是成功率和平均轮数不是单次结果。回归测试测稳定性。同一批任务跑多次看结果一致性。Agent 因为 LLM 的随机性同一任务多次执行结果可能不同。如果差异太大说明 prompt 或者工具设计有问题。部署这块Agent 服务要和无状态服务区别对待。Agent 有状态要考虑会话保持、状态持久化、故障恢复。容器化部署的时候Agent 的状态不能只存在内存里要外部化到 Redis 或者数据库不然容器重启状态就丢了。提示Agent 上线一定要有熔断机制。当错误率超过阈值或者平均响应时间超过阈值自动降级到简单模式或者直接返回兜底话术。我见过有 Agent 因为一个工具挂了整个服务雪崩的案例。5. 常见问题与排查技巧实录5.1 高频错误速查表错误信息根本原因排查方向解决方案agent execution terminated due to error工具执行异常未捕获查工具日志看哪一步抛异常加 try-catch错误信息回传给 LLMllm request failed: provider rejected schema工具 schema 与模型不兼容对比 schema 和模型文档简化 schema去掉模型不支持的字段codex无法发送消息显示更新agent沙盒沙盒环境状态不同步检查沙盒生命周期管理重启沙盒加状态同步机制Agent 循环不结束终止条件未触发查最大轮数设置和终止判断逻辑设硬性最大轮数加超时工具调用参数错误率高schema 描述不清看 LLM 生成的参数和期望的差异补充 description加示例记忆混乱答非所问上下文污染或检索错误查记忆读写日志记忆隔离按意图路由检索5.2 几个我踩过的坑和对应的解法坑一工具描述写得太简略。早期我觉得工具名够清楚就行了description 随便写写。结果 LLM 经常选错工具或者该调工具的时候不调。后来我把 description 改成什么时候用而不是是什么准确率提升明显。比如查询天气改成当用户询问某地天气、温度、是否下雨时调用LLM 的判断准确多了。坑二错误信息直接抛给用户。Agent 执行失败的时候早期我直接把异常信息返回给用户用户体验极差。后来改成两层底层错误信息给 LLM 看让它尝试修正如果修正不了给用户一个友好的兜底话术同时后台记录详细错误。坑三忽略 token 消耗监控。有一次上线一个 Agent没做 token 监控月底账单出来吓了一跳。后来加了实时监控每个会话的 token 消耗超过阈值就告警同时优化了上下文管理成本降了 60%。坑四多 Agent 通信没有超时。多 Agent 协作的时候一个 Agent 等另一个 Agent 的响应如果对方挂了这边就一直等。后来所有 Agent 间通信都加了超时超时后走降级逻辑。坑五记忆没有版本控制。Agent 的记忆结构改了一次老数据读不出来。后来记忆结构加了版本号读取的时候按版本做兼容转换。5.3 性能优化的几个实操技巧Agent 的响应速度是用户体验的关键。几个优化点并行工具调用如果多个工具之间没有依赖让 LLM 一次返回多个调用请求并行执行流式输出LLM 生成的时候边生成边返回用户感知的等待时间大幅缩短缓存相同或相似的查询结果缓存起来特别是工具调用结果。还有一个容易被忽略的点prompt 的精简。system prompt 不是越长越好冗余的指令会稀释关键指令的权重。我定期会做 prompt 的瘦身把不生效的指令删掉把重复的合并实测下来响应速度和准确率都有提升。6. 学习路线与方向判断6.1 新手入门先跑通再优化agent for beginner、agent开发学习路线这些词说明很多人在找入门路径。我的建议很直接别一上来就学框架。先用原生 API 手写一个最简单的 Agent就一个工具一个循环跑通为止。这个过程你会理解 Agent 的本质就是一个LLM 调用 工具执行的循环。跑通之后加第二个工具加记忆加错误处理。每一步都自己写不要抄框架的代码。等你把单 Agent 玩明白了再去看多 Agent 框架这时候你就能看懂框架在解决什么问题而不是被框架的概念绕晕。学习资源这块吴恩达的 Agent 教程质量不错适合建立整体认知。但教程看完一定要动手光看不动手等于没学。我见过太多人教程看了一堆自己写的时候连工具 schema 都定义不明白。6.2 方向判断哪些值得投入哪些是泡沫2026 年这个节点上Agent 和 LLM 领域有几个方向是确定有价值的Agent 的可观测性怎么知道 Agent 在干什么、为什么这么干、记忆管理怎么让 Agent 记住该记的、忘掉该忘的、安全与权限怎么让 Agent 在可控范围内自主。这几个方向是工程落地的刚需不是概念炒作。相对泡沫的方向通用 Agent什么都能干的 Agent 目前不存在、完全自主的 Agent高风险场景下人工介入不可少、纯 prompt 工程prompt 重要但天花板有限真正的提升要靠架构和工具设计。llm驱动的公立医院债务风险智能预警与化解策略研究这种词说明 LLM 正在往垂直行业渗透。这个方向是对的但要注意垂直行业的 LLM 应用领域知识比模型能力更重要。你模型再强不懂医疗术语、不懂金融规则做出来的东西也没法用。所以垂直方向的机会在于懂行业 懂 LLM的复合型人才。6.3 我个人的一些判断做了这几年 LLM 和 Agent我最大的体会是这个领域变化快但底层逻辑变化慢。工具在变、模型在变、框架在变但怎么把模糊目标拆成可执行步骤、怎么管理状态和记忆、怎么处理错误和边界这些核心问题和传统软件工程是一脉相承的。所以我的建议是不要追每一个新框架、新模型把精力放在底层能力的建设上。你的 Agent 架构设计得好换什么模型都能跑你的工具 schema 设计得好换什么框架都能用。反过来如果底层没打好追再多新东西也是浮沙建塔。最后分享一个我一直在用的判断标准如果一个 Agent 方案你说不清楚它在什么情况下会失败、失败了怎么恢复那它就不具备上线条件。这个标准帮我避开了很多看起来很美但实际不能用的方案。Agent 和 LLM 的技术精选日报每天都有新东西但真正能落地的永远是那些把基本功做扎实的方案。