在 Hacker News 上看到“Is Agentic Programming a Flop?”这个讨论时我第一反应是这个词已经被用得太滥了。它一边被翻译成“智能体编程”一边又被等同于“让 AI 自己写代码”。如果连基础概念都没有对齐讨论是不是 Flop 就只会停留在口号层面。这里先把概念拆清楚再搭一个能跑的 Agentic RAG 例子然后用工程视角回答Agentic Programming 到底适不适合进入生产。这个问题的背景很容易理解。过去一年里几乎每个 LLM 应用都会在演示里加一个“Agent”关键词好像只要让模型调用几个工具产品就自动化了。真正落地后才发现Agent 的决策不稳定、工具调用容易循环、上下文窗口容易被工具结果刷爆调试难度比传统后端大得多。于是又开始出现反向论调认为 Agentic 已经凉了。我更倾向于另一个判断Agentic Programming 不是一个非黑即白的技术它是一套“控制流从代码迁移到模型”的编排思路。问题不在它能不能用而在于你有没有为模型画好边界。1. 先搞清楚 Agentic Programming 在争什么1.1 传统控制流为什么不适合“任务自动拆解”传统编程里控制流是写死的。比如一个订单处理流程通常就是if、else、for、while组成的固定执行路径。每个分支都提前定好代码执行时会严格按照开发者设计的逻辑走。这种模型的优点是确定性强、可测试、可审计。问题是当任务本身带有很强的开放性时比如“帮我分析这份报告并给出三个值得关注的风险”传统程序很难把“分析”“归纳”“判断”这类动作拆成精确的代码路径。你当然可以写规则但规则的组合会随着业务复杂度呈指数增长。所以传统编程更适合“输入明确、步骤明确、输出明确”的确定性任务。遇到需要临场推理、多步规划、信息汇总的场景就需要另一种执行方式。1.2 Agentic Programming 的本质控制权让渡给模型Agentic Programming 的核心变化是“下一步做什么”不再完全由开发者写死而是由大模型根据当前上下文、工具反馈和用户目标在线决定。一个典型的执行循环如下用户提出一个开放式目标。Agent 读取当前状态和可用工具。模型输出一个决策是直接回答还是调用某个工具。工具执行后把结果作为观察写回上下文。模型继续判断下一步直到产出最终结果。这个循环在学术上常被描述为 ReAct即 Reasoning Acting。模型先推理再行动再观察再推理直到收敛。Agentic Programming 就是围绕这个循环实现的编程范式。它也解释了为什么 Agent 应用通常接入 LangChain、LlamaIndex、AutoGen 等框架因为你需要一套机制把工具注册、状态管理、推理循环、多轮对话、错误恢复串联起来。1.3 一个容易被误解的边界不是所有 LLM 应用都是 Agentic很多人把“只要用了 Prompt 模板”就叫 Agent这并不准确。普通 LLM 应用的结构通常是用户输入Prompt 处理模型生成输出整个过程中没有工具调用、没有状态更新、没有自主决策它本质上是“单轮生成”。Agentic 应用至少需要包含四个要素目标用户给出的开放性任务。工具模型可以调用的外部能力。循环模型可以多次行动并观察结果。终止条件得到答案、达到最大轮数、用户中断或触发异常。如果少了其中一个只能说这是“带工具的问答”而不是 Agent。这个边界很重要否则很容易把普通 LLM 应用的失败归因到 Agentic 身上或者反过来把 Agent 框架的复杂度归因到 LLM 本身。1.4 为什么有人开始问“是不是 Flop”这个疑问并不是凭空出现。Agent 应用在演示阶段很惊艳因为模型确实能自己规划步骤。进入生产后会遇到几个扎眼的问题模型这一轮选择调用工具下一轮可能就不调用。一个简单问题被拆成五六个工具调用成本高且响应慢。工具返回结果后模型不一定能正确抽取关键信息。缺少统一的评估体系很难说一个 Agent 应用“做对了”。这些问题叠加在一起就会让人产生“Agentic 编程失败了”的印象。但更准确的说法是早期 Agent 应用把太多决策权交给了模型工程约束没有跟上。2. 支持与反对双方到底在争哪几个问题2.1 支持方看到的收益动态规划、低代码编排、复杂步骤自适应支持 Agentic Programming 的人通常来自两类场景。一是任务路径不固定的场景。比如企业知识库问答用户可能问“帮我找出所有关于退款政策的文档并总结其中的争议点”。传统 RAG 通常只会做一次检索然后把检索结果拼进 Prompt。Agentic RAG 则可以分解成“检索退款政策”“提取争议点”“总结输出”多个步骤每一步依赖前一步结果。二是需要组合多个工具的场景。比如“查一下上海未来三天天气再计算适合露天活动的概率”。Agent 可以分别调用天气接口和计算器再把结果组合出来。这种能力让开发者不必预先写死每一步调用而是让模型根据任务动态拼接。从产品角度看这确实降低了长尾流程的编排成本。以前有一百种用户问题可能需要写一百条规则分支现在只要把工具定义清楚模型可以自动覆盖大量组合路径。2.2 反对方看到的成本不可预测、审计困难、评估缺失、token 失控反对一方的理由也很具体。首先是不可预测。同一个问题在大模型参数或 Prompt 稍微变化时Agent 可能走完全不同的工具路径。这导致测试用例很难稳定覆盖。其次是审计困难。传统代码的执行路径可以从日志里完整还原因为每一步都是代码触发。Agent 则不同日志里除了工具输入输出还夹杂着模型自由生成的“思考内容”。你很难确定模型为什么选择某个工具只能回看推理文本。第三是评估缺失。一个普通接口可以用断言、单元测试、集成测试来验证。Agent 应用的结果是自然语言工具调用是否最优没有唯一答案甚至正确答案本身就带有开放性。最后是 token 失控。Agent 把每一步决策都放进上下文调用次数越多token 消耗越大。如果模型陷入循环账单会迅速膨胀。2.3 用一张表看控制流差异维度传统编程Agentic Programming控制流开发者写死模型根据上下文动态决定执行路径确定且可复现不确定但可观测测试方式单元测试、断言评估集、成功率、工具调用路径统计调试重点代码逻辑、数据边界提示词、工具描述、上下文窗口、模型决策成本结构服务资源消耗服务资源 token 消耗适合场景规则明确、高频稳定流程任务开放、路径多变、需要组合工具生产风险低高需要强约束和监控这个对比不是要说哪个更好而是说明二者面向的问题不同。传统编程擅长把稳定流程做深Agentic 擅长把开放流程做活。2.4 当前更成熟的趋势不是去掉 Agent而是约束它的决策空间围绕“Flop”的讨论其实正在推动 Agentic 走向更工程化。一个明显变化是落地项目不再要求模型“自由发挥”而是给它一套窄范围内的行动空间。比如开发者提前定义好模型可以使用哪些工具、每个工具的参数格式是什么、最多执行几轮、哪些操作需要人工确认。模型只在网格内做选择。这就是为什么很多 Agentic RAG 开源项目会强调“可观测”“可干预”“可回退”。它们不再追求一个全自动 Agent而是把 Agent 当作一个“动态路由”让它帮助业务减少规则分支同时对异常决策保留人工接管通道。3. 跑通最小 Agentic RAG从工具到决策循环3.1 案例目标与运行前提为了把讨论落到代码上这里实现一个最小但完整的 Agentic RAG 例子。它解决的真实问题是当用户的问题既需要检索内部知识库又需要做简单计算时Agent 能不能自动决定先调用哪个工具、再调用哪个工具。案例会包含两个工具search_kb从本地知识库中检索相关内容。calculator执行基础四则运算。Agent 需要根据用户问题自行选择工具。比如用户问“退款政策文件里提到的处理时长是多少小时如果再计算它和 24 小时的比例”模型应该先检索再计算。运行前提已安装 Python 3.9 及以上版本。有一个可用的 OpenAI 兼容 API Key通过环境变量OPENAI_API_KEY注入。能联网安装依赖代码中的向量库和 Agent 框架都通过 pip 安装。如果原始模型不支持工具调用可以把模型换成支持 function calling 的gpt-4o-mini或本地部署的兼容模型。落地前要先确认依赖版本下面代码示例只用于说明思路。3.2 环境准备依赖、密钥、项目结构先安装依赖pip install langchain langchain-openai langchain-community langchain-text-splitters chromadb python-dotenv为了可复现建议在 requirements.txt 中锁定版本。这里的核心依赖如下langchain langchain-openai langchain-community langchain-text-splitters chromadb python-dotenv项目目录结构建议这样组织agentic_rag_demo/ ├── .env ├── requirements.txt ├── agent.py ├── tools.py └── docs/ └── qa_kb.txt.env文件内容OPENAI_API_KEY你的_API_KEY注意.env不要提交到 Git。生产环境应通过密钥管理服务注入。3.3 提供一个本地 RAG 检索工具避免一开始就依赖外部服务先用tools.py实现一个本地知识库检索工具。为了演示方便这里用FakeEmbeddings生成假向量不依赖外部 embedding 服务。生产环境可以换成OpenAIEmbeddings、HuggingFaceBgeEmbeddings或本地向量模型。# tools.py from langchain_core.documents import Document from langchain_community.embeddings import FakeEmbeddings from langchain_community.vectorstores import Chroma from langchain_text_splitters import RecursiveCharacterTextSplitter QA_DOCS [ Refund policy: the standard processing time is 48 hours., Agentic programming is a paradigm where an LLM decides the control flow., RAG improves answer quality by retrieving evidence before generation., Spatiotemporal composability means combining data across space and time., Customer support teams often use internal KB to answer refund questions., ] def build_retriever(collection_name: str demo_kb): splitter RecursiveCharacterTextSplitter(chunk_size60, chunk_overlap10) docs [Document(page_contenttext) for text in QA_DOCS] chunks splitter.split_documents(docs) vectorstore Chroma.from_documents( documentschunks, embeddingFakeEmbeddings(size32), collection_namecollection_name, persist_directory./chroma_db ) return vectorstore.as_retriever(search_kwargs{k: 2}) def search_kb(query: str) - str: retriever build_retriever() docs retriever.invoke(query) if not docs: return No relevant document found. return \n.join([doc.page_content for doc in docs])这里有一个关键点FakeEmbeddings只是把文本映射成随机但固定的向量目的是让本地示例不依赖外部模型服务。真实业务里不能用假 embedding 做生产检索否则召回结果没有语义相关性。3.4 提供一个安全计算器工具计算器工具用来演示 Agent 调用非文本类工具的能力。这里不直接使用eval而是用operator处理简单四则运算避免在生产示例中引入不安全隐患。# tools.py 追加 import operator OPS { : operator.add, -: operator.sub, *: operator.mul, /: operator.truediv, } def calculator(expr: str) - float: expr expr.replace( , ) for op in OPS: if op in expr.strip().replace(-, , 1): left, right expr.split(op, 1) left_f float(left) right_f float(right) result OPS[op](left_f, right_f) return round(result, 6) raise ValueError(Expression must contain a valid operator)对calculator的说明它只接受数字 操作符 数字的形式不支持括号和连续计算。一旦出现无法解析的表达式会抛出异常Agent 框架会把异常作为观察返回给模型再由模型决定如何修正。生产环境如果确实需要运行任意 Python 代码应该使用E2B、Pyodide、容器沙箱等安全执行环境不能直接暴露 Python 原语。3.5 用 Tool Calling Agent 把它们组合起来在agent.py中创建 Agent# agent.py from dotenv import load_dotenv from langchain.agents import AgentExecutor, Tool, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI from tools import calculator, search_kb load_dotenv() tools [ Tool( namesearch_kb, funcsearch_kb, descriptionSearch the internal knowledge base for refund, policy, and RAG related documents. Useful when the user asks about known facts. ), Tool( namecalculator, funccalculator, descriptionPerform basic arithmetic operations. Input must look like 12 * 36 or 48 / 24. ), ] prompt ChatPromptTemplate.from_messages([ (system, You are an agent that helps user answer questions. Use the provided tools when necessary.), (human, {input}), (placeholder, {agent_scratchpad}), ]) llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_tool_calling_agent(llm, tools, prompt) agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations5, handle_parsing_errorsTrue, ) if __name__ __main__: query What is the refund processing time in hours, and what is the ratio of that time to 24 hours? result agent_executor.invoke({input: query}) print(result[output])使用create_tool_calling_agent的核心好处是框架会要求模型输出结构化的工具调用参数而不是让模型自由编一段文本。模型决定调用search_kb时会把{query: refund processing time}这样的参数交给工具。3.6 给 Agent 加上执行限制上面的代码里已经包含几个关键限制max_iterations5最多执行 5 轮推理和工具调用防止无限循环。handle_parsing_errorsTrue当模型输出无法解析为合法工具调用时把错误信息返回给模型让它自行修正。temperature0降低生成随机性让 Agent 更容易稳定复现工具调用路径。执行下面的命令python agent.py如果一切正常日志会显示模型先调用search_kb再调用calculator最后输出结果。如果模型能力不足或工具描述太模糊Agent 可能在一步内就给出答案或者反复调用同一个工具。4. 核心机制拆解工具注册、记忆与 ReAct 循环4.1 工具注册表Agent 的能力边界由开发者定义Agent 不是所有能力都来自模型它只能调用开发者注册过的工具。工具注册表是一个典型的“能力白名单”。在设计工具时要注意名称和描述是模型理解工具用途的唯一依据。描述要写清这个工具能做什么。输入格式是什么。什么场景下应该调用它。什么场景下不应该调用它。例如calculator的描述里必须写明“Input must look like 12 * 36”。如果描述写得太泛模型可能会往里面传入任意文本导致工具解析失败。工具不是越多越好。每多一个工具模型就要额外判断一次是否调用它。工具数量超过一定阈值后选择准确率会下降。这也是为什么生产环境更推荐把 Agent 按业务域拆分成多个小 Agent而不是做一个“什么都能干”的大 Agent。4.2 ReAct 循环推理-行动-观察如何运转ReAct 是 Agent 循环的基础模式模型根据用户输入和当前上下文输出一个推理片段。模型决定是否调用工具并生成工具参数。Agent 框架执行工具把结果返回为 Observation。模型把 Observation 和之前的思考拼接继续推理。直到模型认为不需要再调用工具才输出 Final Answer。这个循环看起来简单但工程实现时有很多隐蔽问题。比如某一次工具返回的结果特别长会把后续推理需要的上下文挤掉再比如上一次工具输出中包含“无法找到答案”模型可能会直接编造一个答案而不是尝试其他工具。所以在设计 Agent 时不仅要考虑“模型能力”还要考虑“工具输出的稳定性”。一个好的工具应该让输出尽量短、结构化、包含关键字方便模型读取。4.3 上下文窗口与记忆策略Agent 每执行一轮都会把新的思考、行动、观察追加到上下文。如果工具输出非常长或调用轮数很多上下文窗口很快会被占满。处理方式有三种限制单次工具输出的长度比如只返回摘要或前几条结果。使用外部记忆把历史关键信息保存到数据库或向量库每次只注入与当前任务相关的片段。对 Agent 执行轮数做硬限制超过阈值就强制结束并返回已收集信息。在 RAG 场景里推荐把检索结果先做摘要再返回给模型而不是直接把大段文档塞进上下文。原始文档可以保存在外部数据库摘要作为 Agent 的观察。4.4 为什么 Agent 会“打转”以及它暴露出的工程问题Agent 打转通常表现为反复调用同一个工具参数却几乎一样。已经拿到答案关键信息仍继续执行后续工具。在工具 A 和工具 B 之间来回切换没有收敛趋势。出现这些问题的根本原因是模型没有足够的信息判断“什么时候应该停止”。你只告诉它能调用哪些工具没告诉它什么情况下必须停止。工程上的解法不是单纯地升级模型而是给 Agent 增加“终止条件”。比如在 Prompt 里写明“如果你已经找到足够信息直接输出最终答案不要继续调用工具”。在工具返回结果中加入“该结果可信度已经足够”的标记。用规则层拦截重复调用如果最近两次工具参数相同则强制结束。这些约束属于“决策空间限制”是 Agent 进入生产环境前必须补上的一环。5. 运行验证与结果分析5.1 用三条问题验证 Agent 的决策行为为了验证 Agent 是否真的具备“动态决策”能力这里准备三个测试问题What is the refund processing time in hours, and what is the ratio of that time to 24 hours?What is 16 * 8?Is there any document about spatiotemporal composability?每个问题对应不同决策路径问题 1 需要先检索知识库再调用计算器。验证 Agent 是否能组合两个工具。问题 2 只涉及计算不涉及检索。验证 Agent 是否会跳过 RAG直接调用计算器。问题 3 只涉及检索不涉及计算。验证 Agent 是否会调用search_kb并给出答案。5.2 预期日志长什么样使用verboseTrue后运行 Agent 会输出类似下面的交互 Entering new AgentExecutor chain... Invoking: search_kb with {query: refund processing time hours} Refund policy: the standard processing time is 48 hours. Invoking: calculator with {expr: 48 / 24} 2.0 The refund processing time is 48 hours. The ratio of 48 hours to 24 hours is 2.0. Finished chain.这个日志说明 Agent 成功完成了两步决策。第一轮它认为需要从知识库获取答案第二轮它认为需要把结果转换成一个比例于是调用计算器。5.3 什么结果算成功区分任务完成率和成本评估 Agent 是否成功不能只看最终回答是否正确还要看工具调用路径是否合理。推荐记录以下指标任务完成率检查最终答案是否真正回答了用户问题。工具调用次数衡量 Agent 是否过度规划。平均响应时间多轮调用会显著增加耗时。Token 消耗每个 Observation 都会进入模型上下文成本需要统计。回退率Agent 是否经常触发max_iterations或解析错误。如果只问“16 * 8”但 Agent 先检索知识库再调用计算器虽然结果正确这个过程也不算优秀。生产环境要优化的是“在保持正确率的前提下用最少工具调用完成任务”。5.4 失败模式幻觉、误调用、超步数最常见的失败模式有三种。一种是模型在工具没有返回答案时直接编造结果。这个问题出现在工具返回空结果但模型没有“我无法回答”的意识。这时需要在 Prompt 中强调“如果工具没有返回相关内容请直接告知无法回答”。第二种是工具误调用。模型把本不需要工具的问题也交给工具处理比如把纯文本问题传给calculator。出现这种情况通常是因为工具描述没有写明适用边界。第三种是超步数。问题并不复杂但模型反复尝试工具最终触发max_iterations。这时要把verboseTrue的日志翻出来看模型在每一轮思考了什么然后针对性地优化 Prompt 或工具描述。6. 常见问题排查Agent 不按预期执行怎么办6.1 工具永远不触发现象无论问什么问题Agent 都直接给出回答从不调用工具。排查链路先确认AgentExecutor里确实传入了tools而不是空数组。打开verboseTrue观察模型输出是否出现了工具名称但框架没有执行。检查工具描述是否足够具体模型是否能判断当前问题应该调用该工具。确认模型支持 tool calling。create_tool_calling_agent需要模型支持 function calling否则框架无法解析。尝试在 Prompt 里增加指令“When the user asks about facts, always use search_kb.”根本原因通常不是模型不会调用而是它认为不需要调用。优化工具描述和 Prompt 是更有效的手段。6.2 Agent 陷入循环或一直调用同一工具现象Agent 连续多次调用同一个工具参数变化不大最终触发max_iterations。排查链路查看日志确认模型每次调用工具后是否真的观察到了新信息。如果工具返回内容每次都一样说明模型没有得到能够推进任务的信号。尝试让工具输出包含“这是唯一可用信息请直接基于它回答”这样的提示。用stop条件或规则层拦截重复调用。循环问题的本质是“缺少停止信号”。Agent 框架只知道最大轮数模型如果不知道“已经足够”就会继续尝试。所以在工具返回内容中注入判定提示是成本最低的修复方式。6.3 上下文被工具结果刷爆现象工具返回大量文档Agent 后续轮次开始遗忘前面的推理步骤回答质量明显下降。排查链路检查工具返回字符数看看是不是超过了几千 token。优化检索结果只返回 top-k 条并做摘要。把长文档切割成更小的 chunk并在工具函数中限制返回条数。使用外部记忆保存历史对话摘要而不是把全部历史塞进 Prompt。这里最推荐的策略是“工具输出截断 摘要前置”。Agent 需要的是可操作的观察不是长文原文。6.4 模型输出不是合法 JSON现象日志报Could not parse LLM output工具参数没有被正确传递。排查链路检查模型版本是否支持 function calling或是否在推理接口中启用了 tools 参数。降低temperature避免模型因为随机采样导致输出格式不稳定。开启handle_parsing_errorsTrue让框架把解析错误交给模型自修正。如果经常出现考虑换用更稳定的模型或者使用create_react_agent配合结构化 Prompt。问题现象常见原因检查方式处理建议工具永远不触发工具描述不清晰或模型不支持 tool calling开启 verbose 日志检查工具列表优化工具描述换支持 function calling 的模型Agent 陷入循环缺少停止信号工具输出不能推进决策查看重复调用日志检查工具返回工具中加入“已足够”提示增加规则去重上下文被工具结果刷爆工具返回过长统计单次工具输出 token限制返回条数先做摘要再回填输出不是合法 JSON模型版本或参数问题查看解析异常日志降低 temperature开启解析错误处理6.5 上线前检查清单这里整理一份可复用的检查清单适合 Agentic RAG 或类似 Agent 应用上线前逐项确认[ ] 每个工具是否都有明确适用范围和输入格式说明[ ] 是否设置了最大迭代次数和超时时间[ ] 是否对工具返回内容做了长度限制或摘要[ ] 是否记录每一步工具调用的输入、输出、耗时和 token[ ] 是否有针对“无法回答”和“工具返回为空”的 Prompt 兜底[ ] 是否通过评估集验证过典型问题和边界问题[ ] 是否准备了降级路径Agent 失败时能否回到传统流程[ ] 是否对高风险工具加了人工确认或权限隔离这个清单可以直接加到 CI 或发布流程的检查项里减少 Agent 应用上线后的运维事故。7. Agentic Programming 的工程化建议以及它到底是不是 Flop7.1 用“最窄权限”设计 Agent 能调用的工具再强的模型也不应该在没有任何约束的情况下访问生产环境的所有 API。更合理的做法是给每个 Agent 设计一个最小工具集。比如一个客服问答 Agent 只需要读知识库、查工单状态、更新工单标签不需要访问数据库写权限也不需要调用批量删除接口。工具注册表就是权限边界越窄越好。工具内部也要做参数校验。即使模型传入了恶意或非法参数工具函数也要先做校验再执行业务逻辑。不能把模型当作可信输入源。7.2 必须建立可观测性与成本控制Agent 应用观测和传统服务观测不同。除了系统指标还需要记录每次工具调用的模型输入 token、输出 token。工具执行的耗时和返回内容大小。Agent 最终是否收敛还是触发了 max_iterations。每一轮决策的模型思考文本。把这些信息输出到日志中心或 Trace 系统才能回答“为什么 Agent 会这样做”“这次调用花了多少钱”这类问题。7.3 评估集与回归测试是落地前提Agent 应用不能只靠人工抽查。建议准备一个评估集每个用例包含用户输入预期工具调用路径预期最终回答可接受的核心答案片段每次修改 Prompt、换模型、调整工具描述后都跑一遍评估集统计工具调用准确率和答案命中率。只有指标没有退化才允许部署。评估集规模不需要很大先覆盖业务最常见二三十个问题再逐步补充边界问题。关键是让每次变更都有量化结果。7.4 设置降级路径Agent 失败时回到固定流程生产环境里不能把 Agent 作为唯一通道。假设 Agent 超时、循环、解析失败用户仍然需要一个可用的体验。常见降级路径包括直接使用普通 Prompt 生成回答不做工具调用。返回“暂时无法回答请稍后再试”或引导用户联系人工。切换到只读工具集禁用写操作和危险操作。降级路径的本质是保留一个“最不智能但最稳”的兜底方案。Agent 表现好时走动态流程表现差时退回到固定流程这对用户体验和系统稳定性都更友好。7.5 结论从“能不能”到“怎么约束”回到最初的提问Agentic Programming 是 Flop 吗如果把它定义为“让模型完全掌控控制流、自由探索所有可能性”它确实还远没到可以大面积铺开的成熟度。原因不是模型不够聪明而是工程界还没有为这种级别的自主性准备好足够的可观测性、评估体系和权限控制。如果把它定义为“通过明确工具边界、控制循环轮数、建立观测与降级机制让模型在受控范围内动态编排步骤”Agentic Programming 不仅没有失败反而正在成为 RAG、自动化运维、企业内部知识服务等场景里非常实用的技术路径。实际项目中最值得投入的不是买更贵的模型而是把工具协议、记忆策略、评估集和降级链路做扎实。模型负责决策工程负责约束。没有约束的 Agent 可能只是一个昂贵的演示而有了约束的 Agent 才能成为可维护的生产系统。下一步可以做的事很具体先构建一个最小 Agentic RAG 跑通端到端流程记录每轮工具调用的日志再建立一组评估用例最后逐步加入权限控制和可观测性。这一圈走完你自然会对“Agentic 是不是 Flop”给出自己的答案。