Agent 工程化系列 · 第 17 篇Agent 技术问题总结把前 16 篇的关键概念串起来副标题一张工程地图看懂 LLM、Workflow、Function Call、MCP、Skills、A2A、Memory、RAG 与安全可靠性。▌ 开篇定位前面 16 篇我们已经把 Agent 工程化中最容易混淆的一组概念拆开讲了一遍。从 LLM 和 Agent 的边界到 Workflow 的适用场景从 Function Call 的工具调用到 MCP 的连接协议从 Skills 的任务方法到 A2A 的 Agent 协作再到 Memory、RAG、安全可靠性和生产落地。到了第 17 篇不再继续拆新概念。这一篇要做的事情只有一个把前面这些概念重新拼回一张工程地图帮助你判断一个 Agent 系统到底应该怎么设计。▌ 目录 本篇内容01 这篇总结解决什么问题02 第一条主线LLM 是能力核心Agent 是执行系统03 第二条主线Workflow 和 Agent 不是对立而是边界不同04 第三条主线Function Call、MCP、Skills、A2A 分别放在哪05 第四条主线RAG、Memory、安全可靠性是系统底座06 从 Demo 到生产真正难的是什么07 最后留下一个判断框架08 最后总结▌ 01 这篇总结解决什么问题很多人学习 Agent 的时候最大的问题不是不知道某个名词而是把所有名词混在一起。比如看到模型能调用工具就以为 Function Call 等于 Agent看到 MCP 很火就以为 MCP 可以替代 Function Call看到 RAG 可以查资料就以为 RAG 就是 Agent看到 Skills 可以复用任务方法就以为 Skills 是更长的 Prompt。这些理解都只看到了一部分。真正从工程角度看Agent 不是一个单点能力而是一套围绕目标持续推进任务的应用系统。它需要模型能力也需要流程设计需要工具调用也需要协议连接需要外部知识也需要记忆系统需要自动执行也需要安全边界。所以这篇文章的核心判断是Agent 工程化不是“选一个框架”而是把模型、流程、工具、知识、记忆、安全和观测组合成一个可运行系统。▌ 02 第一条主线LLM 是能力核心Agent 是执行系统LLM 是大模型它最核心的能力是理解语言、生成文本、做推理、总结内容、改写表达、分析上下文。但 LLM 本身通常不是一个完整应用系统。它不知道你的业务状态也不会天然知道外部系统的实时数据更不会自己完成权限校验、工具执行、失败重试、日志审计。所以我们在第 01 篇里把边界讲清楚LLM 更像大脑Agent 更像一个围绕目标行动的执行系统。一个最小 Agent 至少会多出这些东西目标理解、任务规划、工具调用、状态记忆、结果校验、反馈循环。如果一个系统只是“用户问一句它答一句”它更像 LLM 应用。如果它可以围绕目标持续推进比如先查资料、再调用工具、再检查结果、再根据结果决定下一步它才更接近 Agent。**工程判断**不要一上来就问“我要不要做 Agent”而是先问这个任务是否需要持续推进、动态决策和外部动作。▌ 03 第二条主线Workflow 和 Agent 不是对立而是边界不同Workflow 是确定性流程。它的路径一般在代码或配置里提前写好第一步做什么第二步做什么异常怎么处理审批走哪条线。Agent 更强调运行时决策。它不是所有路径都提前写死而是在任务执行过程中根据目标、上下文、工具结果和中间状态决定下一步。这就带来一个很重要的工程原则能写成稳定 Workflow 的地方不要为了显得高级硬上 Agent。比如日报生成、固定审批、固定字段抽取、标准报表整理这些场景用 Workflow 更稳。但如果任务本身路径不确定比如“帮我调研这个市场机会并根据资料判断是否值得做”它可能需要搜索、筛选、总结、比较、补充检索、生成报告这时候 Agent 的价值才会出现。最好的工程形态往往不是二选一而是混合大流程用 Workflow 固定住保证稳定性。不确定节点交给 Agent 判断提升灵活性。高风险动作加入人工确认避免执行失控。▌ 04 第三条主线能力接口应该怎么放前面几篇最容易混的是 Function Call、MCP、Skills、A2A。它们都和“让 Agent 拥有外部能力”有关但它们解决的问题不是一层。Function Call 解决的是模型如何用结构化方式表达“我要调用哪个函数参数是什么”。它不是模型真的执行函数而是模型生成调用意图真正执行的是外部应用程序。MCP 解决的是当工具、数据源、资源越来越多时如何用一种标准方式接入它们。它关注的是连接标准和工具生态而不是单次函数调用。Skills 解决的是这类任务应该怎么做。它把高频任务的方法、步骤、模板、注意事项沉淀下来让 Agent 不必每次都靠临时 Prompt 猜。A2A 解决的是当一个 Agent 需要找另一个 Agent 协作时如何发现对方、传递任务、同步状态和交付结果。概念一句话定位在系统里的位置Function Call单次工具调用的结构化请求模型到工具执行的接口MCP工具、资源、提示词的标准化连接协议Agent 与外部能力的连接层Skills可复用任务方法和操作手册Agent 的任务能力包A2AAgent 与 Agent 之间的协作协议跨 Agent 通信层这四个概念不要互相替代地理解。更准确的理解是Skills 规定怎么做Agent Runtime 负责组织执行MCP 暴露可用工具Function Call 发起具体调用A2A 连接其他 Agent 协作。▌ 05 第四条主线RAG、Memory、安全可靠性是系统底座一个 Agent 系统要真正可用不能只靠模型一次性推理。它至少还需要三类底座能力。第一类是 RAG。RAG 解决的是知识问题。模型不知道企业内部文档、最新业务资料、实时数据、用户上传文件时就需要通过检索把外部知识拿回来再让模型基于这些材料生成回答。第二类是 Memory。Memory 解决的是状态问题。它不只是保存聊天记录而是让 Agent 记住当前任务进度、用户偏好、历史结论、已执行动作、下一步计划。没有记忆Agent 每一轮都像重新启动。第三类是安全可靠性。Agent 的危险不是回答错一句话而是执行错一个动作。比如删文件、发邮件、改数据库、下订单、调用生产接口。只要 Agent 能影响真实系统就必须有权限控制、参数校验、人工确认、日志审计、失败恢复。这也是为什么很多 Agent Demo 看起来很强但生产环境不好用。Demo 只需要展示一次成功生产系统需要处理长期运行、异常输入、接口失败、权限边界、用户误操作和恶意注入。▌ 06 从 Demo 到生产真正难的是什么一个 Demo 可以很简单写一段 Prompt接一个模型再接一两个工具。但生产级 Agent 不一样。生产级 Agent 要能持续运行要能知道自己做到了哪一步要能在工具失败时重试要能在关键动作前让人确认要能记录每一次调用要能在输出错误时被追踪和修复。所以从 Demo 到生产真正难的不是“让模型回答”而是让整个系统可控。至少要补齐这些工程能力状态管理任务执行到哪里了下一步是什么。工具治理哪些工具能用参数是否合法权限是否足够。上下文工程哪些信息要放进上下文哪些信息要检索哪些信息要压缩。人工确认涉及真实影响的动作不能完全自动放行。可观测性模型输入输出、工具调用、异常、耗时、成本都要可追踪。失败恢复接口失败、模型输出不合规、用户中断都要有恢复策略。工程上可以把 Agent 看成一个闭环目标理解 → 任务规划 → 工具执行 → 结果校验 → 状态记忆 → 安全边界 → 再进入下一轮。如果少了这个闭环它就很难稳定承担真实工作。▌ 07 最后留下一个判断框架学完前面这些概念最重要的不是背名词而是形成判断。当你面对一个 Agent 需求时可以按下面这套问题逐步判断。这套判断框架的意义是不要先问“用哪个 Agent 框架”。先问任务本身是什么类型它是固定流程还是开放任务它需要外部知识吗它会操作真实系统吗它需要跨 Agent 协作吗它是否高风险只有这些问题想清楚后面选择 Workflow、RAG、Function Call、MCP、Skills、A2A、Memory、Guardrails才不会乱。▌ 08 最后总结Agent 工程化到这里可以收束成一句话Agent 不是更会聊天的大模型而是一套围绕目标持续推进任务的工程系统。LLM 提供理解和生成能力Workflow 提供确定性流程Function Call 让模型产生结构化工具调用MCP 让工具和资源标准化接入Skills 让高频任务方法可复用A2A 让 Agent 之间可以协作RAG 让系统获得外部知识Memory 让系统保持状态安全可靠性决定它能不能上线。最终Agent 工程化不是为了追一个新名词而是为了把 AI 从“能回答”推进到“能稳定交付”。下一篇我们就把视角从当前工程地图往后看Agent 未来会怎么发展从聊天助手到数字员工再到企业协作网络。▌ 参考资料OpenAI Agents SDKAgents、Tools、Guardrails、TracingAnthropicBuilding Effective AI AgentsLangGraphDurable Execution、Human-in-the-loop、MemoryModel Context Protocol SpecificationAgent2Agent Protocol SpecificationOpenAI Function Calling / Structured Outputs / Retrieval / SkillsOWASP GenAI Security ProjectLLM Top 10