接个大模型 API，配几段 Prompt，挂几个 MCP，再画一张多智能体协作图，就敢宣布“AI 员工上岗”。这个行业最该补的课，恐怕不是提示词工程，而是软件工程。
最近看了不少 AI Agent 的产品演示，越来越有一种奇怪的感觉：我们似乎正在用比以往任何时候都低的门槛，把一个原本很严肃的工程概念包装成一场热闹的营销表演。打开网页，输入一句自然语言，模型分析需求、调用工具、读取数据、生成报告，甚至还能主动发送邮件。整个过程丝滑得像魔术。演示结束，屏幕上出现“任务完成”四个字，旁边往往还配着“自主规划”“多智能体协作”“数字员工”的标签。如果再接上一段流程图，把 Planner、Memory、Tools、MCP、RAG 和几个角色方框摆上去，一套“企业级 Agent 平台”就算有了雏形。
但只要多问几句，气氛就可能变得尴尬：工具调用超时怎么办？ERP 已经写入成功，但 Agent 没收到响应，重试会不会重复下单？审批人三天后才回复，任务能否从原来的状态继续？模型把一份过期的工艺规范当成最新版本，系统怎么发现？生产线上同一个设备同时产生两条维修指令，谁来协调？员工离职后，他曾授权给 Agent 的权限会不会立即失效？出了事故，能不能准确还原当时用的模型版本、工具参数、业务数据和执行路径？
如果这些问题都没有答案，那么眼前看到的可能确实是一个很漂亮的 AI 演示，却还算不上能够被企业放心托付业务的系统。让 Agent 在演示视频里成功一次，和让它在真实环境里稳定运行几个月，根本不是同一道题。
一、API 能调用，工具能执行，不代表系统就有了 Agent 能力
API、Prompt、MCP 和 Workflow 降低了 AI 应用开发门槛，都是有用的基础设施。问题不在于工具简单，而在于我们经常把“技术组件已经接通”和“业务能力已经形成”混为一谈。一个模型能读取文档、查询数据库、调用接口，只能证明它获得了一些信息获取和动作执行的能力；至于它能不能在不完整信息下选择正确动作，能不能遵守业务约束，能不能判断自己何时应该停止，完全是另外一回事。
Anthropic 曾在《Building effective agents》中提出一个很有用的区分：Workflow 通常由预先编排好的代码路径组织模型与工具，Agent 则让模型在一定范围内动态决定执行路径和工具使用方式。这个区分不是为了给谁贴上高级、低级的标签，而是提醒开发者理解自己究竟在建什么。流程确定、规则清晰的任务，使用 Workflow 往往更便宜、更快、更稳定；开放性强、步骤难以预设的任务，才更有理由引入 Agent 的自主决策。如今最荒唐的事情，是把固定的五步流程套上一层自然语言入口，就说它具有复杂的自主能力；反过来，也有人为了追逐 Agent 概念，硬把原本用一段代码就能可靠完成的事情，交给多个模型讨论半天。
判断一个系统是不是有价值，不应该看它有几个 Agent、几条 MCP 连接、多少个 Skill，而要看它解决了什么业务问题，并且以什么代价、什么风险、什么可验证的方式解决。自主性本身从来不是目的。企业要买的不是一个“特别会自己做决定”的模型，而是一个在明确授权下能够把事情做成、做对，并且出了问题找得到原因的系统。
二、真正的工程难题，几乎都藏在“正常路径”之外
做演示时，我们通常会精心准备一条幸福路径：输入符合预期，网络没有抖动，工具返回结构标准，文档版本正确，权限恰好足够，模型一次就选中了合适的动作。整条流程从第一步走到最后一步，几分钟就能形成一个令人兴奋的结果。这没有错，原型开发本来就应该快速验证想法。错的是把这条幸福路径当成完整的系统设计。
生产环境首先会教给开发者一个朴素的事实：失败不是偶发事件，而是运行条件的一部分。数据库会锁表，第三方接口会限流，用户会中途修改需求，任务会遇到审批，网络会断开，模型会选错工具，上游系统返回的字段也可能悄悄变化。一个稍长的业务任务，只要需要跨越多个系统、多个角色和多个时间点，就不能再依赖“一次会话里把所有事情做完”的理想假设。
所以生产级 Agent 需要的并不是一句“失败后自动重试”，而是一套真正可运行的任务机制。任务有没有唯一标识？每一步完成到哪里？哪些动作只是读取，哪些动作已经产生不可逆的业务副作用？是否可以从检查点恢复，而不是重新把全部步骤执行一遍？重复执行能否靠幂等键避免重复下单、重复报修？确实无法撤销的操作，是否有补偿流程、人工接管和异常队列？当一个任务等待审批时，算暂停、失败还是完成？当系统重新部署后，未完成任务还在不在？
这些问题听起来没有“自主进化”“认知架构”那么性感，但它们决定了系统究竟是在玩具环境里表演，还是能够承担真实工作的责任。LangGraph 的持久化机制把检查点、跨轮状态和恢复执行作为重要能力；类似地，成熟的 Agent 运行时已经开始围绕状态、暂停、恢复、审批建立基础设施。不是因为这些机制新奇，而是因为任何长时间运行、会修改外部世界的程序，迟早都要面对这些古老的软件工程问题。
三、MCP 解决的是连接问题，不会替你解决业务可信问题
MCP 的价值很大。过去不同系统要分别编写集成代码，现在工具能力可以通过相对统一的方式暴露给模型，Agent 能够更容易地发现和调用外部资源。对于需要连接 PLM、MES、ERP、QMS、文件系统和内部服务的企业 AI 而言，这无疑降低了集成门槛。但也正因为连接容易了，风险更容易被忽略。
想象一下，我们通过 MCP 给一个“采购智能体”提供了查询库存、读取供应商信息和创建采购订单的工具。演示时，它根据一句“帮我补一批物料”就能生成订单，体验相当惊艳。真正进入企业环境后，问题马上出现：谁有资格下单？订单金额上限是多少？供应商是否经过准入？能不能绕过预算与审批？工具返回“调用成功”，是不是意味着订单已经通过 ERP 的业务校验？如果某个外部文档夹带了诱导指令，模型会不会把无关数据发送出去？
**MCP 是连接与交互协议，业务授权和安全控制还得另做。**企业可以通过 MCP 暴露能力，但真正的权限控制必须在服务端和业务系统的执行层落实。模型觉得“可以做”，不等于用户有权让它做；Prompt 里写了“禁止删除”，也不能替代接口级的权限校验。工具调用应有明确的输入输出契约、参数校验、最小权限、审计记录和敏感操作审批。那些能够改变生产计划、释放工单、修改 BOM、删除记录或影响现场控制的动作，更不应该靠模型的一次语言判断直接放行。
OWASP 的 Agentic Applications 安全指南以及 MCP 安全实践都把工具权限、提示词注入、工具污染、供应链和越权调用列为重要问题。连接越多、权限越宽，系统需要解决的攻击面就越大。把一个 MCP Server 配进系统，通常只花很短时间；把它变成可被组织信任的企业工具接口，可能才是真正费工夫的部分。
四、记忆系统不是“存得越多越智能”，知识库也不是建完就能永远正确
现在很多 Agent 架构图里，Memory 一定是一个大方框，旁边配着向量数据库、知识图谱、长期记忆和用户画像。看起来非常完整，但在真实项目中，我们更应该追问：系统究竟需要记住什么？谁负责维护？什么时候过期？出了错误怎么修正？不同用户之间是否会发生信息串用？模型从记忆中读到一个结论，能否追溯到可信的源文件？
其实 Agent 至少要区分几类完全不同的东西。当前任务的执行状态，应该由可靠的任务存储和检查点来管理；企业事实、产品规范和工艺要求，应优先从有权限、有版本的权威数据源检索；用户偏好、上下文摘要和长期经验，则需要专门的更新、冲突处理、生命周期与清理机制。不能因为这些东西都被叫作“记忆”，就全部塞进一个向量库，然后指望模型自动处理真实性和时效性。
尤其在工业环境里，过时知识的危害可能比知识缺失更大。一份旧版检验规程，一张失效的工艺卡，一条没有经过验证的设备故障经验，如果被检索结果包装成“系统记忆”，就很容易成为貌似合理的错误依据。与其不分青红皂白地把整个企业文件夹全部向量化，我们更愿意优先做好文件发现、权限过滤、版本识别、按需检索和必要时的精细索引。把源文件留在可管理的知识体系里，比让一堆脱离来源的语义片段在数据库中长期漂浮，更符合企业知识治理的常识。
所谓长期记忆，更不能等同于“永远追加”。一个成熟的数字工匠应当知道哪些只是临时讨论，哪些是已审批的标准，哪些是从历史案例归纳出来、尚需验证的经验。它应该能说“我找到三个互相冲突的版本，需要确认”，而不是永远自信地给出一个答案。好记忆的标准不是容量，而是来源可信、更新及时、权限正确、冲突可见。
五、模型换了，Prompt 改了，系统为什么就可能变成另一个产品？
传统软件也会因为依赖升级出现兼容性问题，但 Agent 系统多了一层非常特殊的不确定性：相同业务目标下，模型可能采用不同的推理路径、选择不同的工具、生成不同的参数。升级模型、修改系统提示词、添加一个新工具、更新某个 Skill，都可能改变整条任务链路的行为。一个原本稳定的功能，也许突然多问了一次问题，绕过了一步确认，或者把输出字段换成了另一种格式。
因此，Prompt 和 Skill 当然重要，但它们首先应被视为需要管理、测试和发布的系统配置，而不是越积越多的“智慧资产”。Skill 有多少个不值得炫耀；我们真正关心的是，它们在什么场景被调用、带来了多少增益、造成过哪些错误、是否与其他规则冲突。知识库是不是越来越大，也不值得独立庆祝；应该关心检索命中率、答案引用正确率以及旧版本误用情况。对于那些必须百分之百满足的业务约束，更不应该只写在系统提示词里，祈祷模型自觉遵守。
例如订单金额必须在授权范围内，工艺参数必须满足已验证边界，某类操作必须双人复核，这些都应该由确定性的规则引擎、权限系统、参数校验和审批机制落实。模型可以解释规则、发现异常、推荐下一步，但最终的硬门槛应交给可测试、可复现的工程代码。AI 的概率性输出与业务系统的确定性控制，不是二选一；真正靠谱的 Agent，恰恰要把两者放在合适的位置。
六、没有日志、追踪和评测的 Agent，连自己是否退步了都不知道
很多项目把“能跑通”视作测试结束，把几段用户好评视作效果证明。可一旦系统上线，就会面临一个非常现实的问题：今天的 Agent 比昨天更好了吗？刚升级的模型到底提高了任务成功率，还是只是说话更漂亮？某个工具调用慢了，是模型决策变差，还是接口性能出了问题？失败集中在什么任务类型？系统总成本是否已经超过人工处理？
要回答这些问题，日志只是起点，还需要贯穿整个任务的追踪能力。一次任务从接收需求到生成计划，从检索文件到调用工具，从审批暂停到最终交付，每一步都应能关联到同一个任务标识，并记录模型与配置版本、工具名称、输入参数摘要、返回状态、耗时、重试、异常和人工接管节点。涉及敏感数据时，记录同样要遵循脱敏、访问控制与保留策略。否则系统出了问题，开发团队只能盯着一份最终回答猜测中间发生了什么，运维人员也很难找到真正的故障点。
评测则是比日志更进一步的事情。单轮回答看起来正确，并不代表整条业务链完成得正确。对于企业 Agent，至少应分别观察任务端到端成功率、业务结果正确率、人工干预率、越权与高风险操作拦截情况、失败恢复能力、执行时延和单位任务成本。还应该建立一组真实业务场景的回归样本，包括格式错误、接口超时、重复请求、权限不足、知识冲突、任务中断、审批拒绝以及恶意输入。每次模型、Prompt、工具或编排机制发生变化，都应重新跑关键场景。
OpenAI 的 Agent 工程文档已经把 tracing、guardrails、human review、状态与评估放入正式的开发体系。这并不意味着使用某个 SDK 就自动获得了生产级质量，而是说明业界越来越清楚：真正的工程问题远不止“如何让模型发起下一次工具调用”。没有可观测性，就没有可靠的故障定位；没有持续评测，就谈不上可信的能力进化。
七、到了工业现场，漂亮的 Agent 演示尤其容易露馅
不妨设想一个典型的设备维护场景。操作人员对数字工匠说：“三号产线这台设备最近振动异常，帮我分析一下，安排检修。”在演示环境里，这是一条很适合展示的业务链：模型查询传感器时序数据，检索设备手册，分析历史维修记录，生成故障判断，最后创建一张维修工单。屏幕上流程一个节点接一个节点变绿，客户很容易觉得“智能工厂已经实现了”。
但在真实的工厂里，振动异常是否可靠，首先取决于传感器校准状态、采样频率、设备工况和数据质量。历史维修记录对应的是不是同一个设备、同一型号、同一配置？设备当前是否处在检修窗口？工单是否与正在执行的生产计划冲突？需要停机的话，谁有权批准？备件库存是否可信？模型分析出的可能原因是经验判断、统计异常，还是经过试验验证的诊断结论？如果系统把“可能存在轴承问题”写成“已经确认轴承故障”，后续的维修资源就可能被错误调度。
到了这一步，系统能力的核心已经不再是会不会调用几个工具，而是能不能协调 MES、设备管理系统、库存、权限、班组和审批，能不能理解数据的边界，能不能把分析结论与执行指令分开。特别是涉及 PLC、生产设备和安全联锁时，AI 不应绕开原有控制体系直接发布高风险指令。一个合理的工业智能体，可以自主搜集证据、整理备选方案、填好工单草稿、识别流程节点，但涉及停机、修改关键参数或其他危险操作时，必须服从经过验证的控制逻辑和授权审批。
工业智能体照搬通用聊天机器人的做法，在这里行不通。工业现场需要的不是“什么都敢做”的代理，而是“知道自己能做到哪里”的数字工匠。真正体现价值的，往往是它把工程师原本需要跨几个系统、查几十份资料、核对多个版本才能完成的工作，压缩成一条可追溯、可复核、可交接的业务链，同时保留必要的专业判断和组织责任。
八、多智能体不是高级感的证明，复杂架构有时只是复杂问题的制造机
一个 Agent 还没做稳，架构图上就又增加了五个。负责规划的 Agent、负责检索的 Agent、负责执行的 Agent、负责审核的 Agent、负责总结的 Agent，名字听起来很完整，架构图也确实漂亮。但每增加一层模型交互，就可能增加新的上下文损耗、延迟、费用、错误传播和责任边界。多个模型彼此认可，不意味着它们共同得到了正确答案；一个模型提出错误假设，后面几个模型围绕错误假设继续协作，反而可能让整个系统更自信。
多智能体当然有适用场景，比如不同专业领域确实需要独立分析、任务能够并行拆解，或者需要明确的分工与结果汇总。但在引入复杂协作前，应当先回答一个简单问题：为什么单智能体加上确定性的工具和流程不能完成？如果两个角色经常交换大段重复上下文，或者所谓“审核 Agent”只是在复述执行 Agent 的结论，那么这套架构可能更多是在制造 Token 消耗，而不是制造业务价值。
我们真正需要的不是 Agent 数量竞赛，而是把任务拆分粒度、角色责任、共享状态、权限隔离和结果验收设计清楚。该并行的任务并行，该由程序计算的就由程序计算，该让模型判断的才交给模型判断。很多时候，一个边界清晰、工具可靠、可恢复、可评测的 Agent，比十个互相聊天的 Agent 更接近企业需要的“智能”。
九、生产级 Agent 的分水岭，是企业敢不敢把责任交给它
如果要用一个标准判断 Agent 是否真的完成了从演示到产品的跨越，我更愿意问：企业敢不敢让它持续处理真实任务，并且不必时时有人守在旁边替它收拾残局？这里的“不必时时守着”，不代表取消人类审批，而是说系统应当拥有稳定的边界管理和异常处理能力，知道什么时候可以自动继续，什么时候应该暂停，什么时候必须升级给专业人员。它不能只在成功时报告“我完成了”，还要能在失败时明确说明“做到哪一步、哪些动作已经生效、为什么停下来、接下来由谁处理”。
对于企业而言，这意味着 Agent 项目验收也需要改变。除了展示功能点，还应拿真实的任务样本做试运行，设置足够长的观察周期，覆盖接口波动、业务变更和人员交接，核对实际业务系统中的执行结果。模型替换、权限调整、工具升级后，应当能够看到回归测试和风险评估结果。对于高风险工作，系统要证明自己不会越权，而不只是证明自己会操作。对于低风险但高频的工作，则要证明成本、稳定性和吞吐量确实优于原来的方法。
与其在 PPT 里写“支持自主规划、自主反思、自主进化”，不如把下面这些问题回答清楚：任务成功率如何测量？失败后如何恢复？写操作如何保证不重复？数据和权限由谁控制？异常时谁接管？系统升级后如何证明没有退化？审计时能否复盘？这些问题听上去朴素，但它们才是企业真正愿意签字验收的依据。
十、AI Agent 的竞争，最终会回到工程常识
Agent 热潮带来了实用的新工具。大模型让软件有机会以自然语言理解目标、适应不完整指令，并在一定范围内动态组织工具，这是非常值得投入的技术方向。接 API、写 Prompt、连 MCP、跑 Workflow，也完全是合理的起点。我们真正需要警惕的，是把起点包装成终点，把能够演示的能力误当成能够承担责任的能力，把模型的聪明当成整个系统的可靠。
过去几年，行业花了很多力气证明“AI 也能做这件事”。下一阶段，更有价值的问题应该是：“它为什么在真实环境里还能一直做对？如果做错了，我们能不能及时发现、阻止损失、恢复状态，并且让下一个版本少犯同样的错？”这需要模型能力，也需要传统软件工程、业务流程、权限治理、测试体系和运维体系共同发挥作用。某种意义上，Agent 越有自主能力，我们就越需要把它周围的工程边界做得扎实。
**Agent 的价值，不在于它看起来像个人，而在于它能够像一个负责任的企业系统一样工作。**它应该拥有足够的智能去理解复杂任务，也必须拥有足够的约束去尊重业务现实。把不确定的推理留给模型，把确定的规则交给系统，把不可逆的决定留给有权限的人；让每一次执行都有记录，每一次失败都有去处，每一次升级都有证据。
所以，再看到有人拿一段三分钟的视频宣布“AI 员工已经取代人类”，我更想问的不是它接了哪个最先进的模型、支持多少 MCP，或者用了几个 Agent，而是一个听起来有点扫兴的问题：视频结束以后，系统出了错，谁负责？
能回答这个问题，Agent 才算真正开始走向工程化。
参考资料
- Anthropic, Building effective agents (2024). https://www.anthropic.com/research/building-effective-agents
- OpenAI, Agents SDK，以及 Guardrails and human review、Integrations and observability. https://developers.openai.com/api/docs/guides/agents/sdk
- LangGraph, Persistence. https://docs.langchain.com/oss/python/langgraph/persistence
- OWASP, Top 10 for Agentic Applications for 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- OWASP, MCP Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html