2026年，企业内部对Agent的反馈已经分成明显的两拨：一拨还在做演示，另一拨已经把高频动作交给Agent自治。差在哪？差在工程侧，也就是能不能把“别只聊天”这个期望，拆成模型、工具、记忆、权限四条可执行的线。
1. 从Chatbot到Agent：要补的不是模型，是执行链路
传统Chatbot接到一个问句，返回文本即结束。Agent接到目标后，要拆步骤、查数据、调工具，涉及业务动作时还要等确认。一条最基本的链路是：
用户请求 -> 任务计划 -> 工具调用 -> 结果观察 -> 收尾汇报
这个链路里，决定生产可用性的不是参数规模，而是下面四件事有没有落到系统设计里。
工具通道。 演示环境里的成功调用只能说明API通。生产环境的超时、限流、参数错误、返回结构变化，每一项都会让Agent卡住。加一层统一网关，把鉴权、超时、重试、限流放在同一个位置，再把API返回结构转成模型容易消费的格式，比反复改提示词更管用。
记忆边界。 上下文窗口再大，也不该把所有对话历史塞进去。建议拆成会话摘要、用户画像、知识库检索三个独立模块，按需读取。长期记忆要持久化，让Agent中断后还能继续未完成步骤。
权限边界。 Agent调工具的权限，应该等于岗位权限，而不是服务号的管理员权限。API Key权限过大，模型犯的任何一个错都会被放大。在权限粒度上收紧，比调模型参数更能减少事故。
这四件事同时到位，一个系统才从“会聊”进入“能办事”的候选名单。
2. 单点ROI：客服、运营、研发助手的账要分开算
企业问“Agent到底省了什么人效”，最怕听到一个平台级总数。要按场景分拆，分别设一个可对照的基线。
客服：圈定高频问题做灰度对照。 客服场景最容易起步，但账不能拍脑袋。选一个知识库完善的咨询队列，按用户ID切20%流量进入Agent辅助坐席模式；同一班组内做前后两周对比，记录平均处理时长（AHT）、转人工率、一次解决率。如果AHT没有降、转人工率没有变，说明只是语气变好了，效率没有变。
运营：从每天重复5次以上的动作切入。 比如批量更新商品信息、同步客户标签、替换活动物料。先让Agent输出变更方案，负责人审批后再执行。单点ROI可以按“一次操作的原耗时 × 一天触发次数”来算。如果所选动作一天触发不到一次，这个自动化不值得立项。
研发助手：衡量的是“找回上下文的时间”。 研发助手的价值不在补全代码多快，而在减少工程师翻文档、翻历史代码的打断时间。可观测指标可以是：新员工完成一个指定模块改造的耗时、一次代码评审从发起到合并的时长。建议把指标和需求交付周期放在一起看，免得代码写快了但系统不稳。
3. 技术选型：自研Agent框架和MCP生态负责两层不同的事
工具协议领域的进展让这个选择题简化了。由Anthropic发起并开源的MCP（Model Context Protocol），到2026年已是很多企业接入外部工具的常见口径，多家模型厂商陆续支持，一套工具可以接到多个Agent服务上。这意味着工具层不必自造标准，真正需要做选择的是编排层。
这里所说的编排层，指任务拆解、执行循环、记忆调度这一层。它可以选择开源框架，由团队自己控代码；也可以直接使用供应商的Agent平台。两者的取舍要看四点：
- 现有业务系统部署在私有化环境还是公有云；
- 工具数量和变更频率，如果每周都会增减API，越开放越好；
- 是否要为多个业务线重复搭建同一套能力；
- 团队有没有能力维护一个长生命周期的自研运行时。
如果决定自研，建议不要在每个业务服务里直接调大模型API，而是抽出一个轻量运行时，对外提供三个接口：模型调用、工具调用、记忆调用。框架层用LangGraph、Semantic Kernel这类开源项目起步，进度会快很多。
4. 供应商锁定：更值得留意的是数据和流程的迁出成本
MCP解决了工具层一部分兼容问题，但没有解决全部。真正容易锁住企业的，往往是三样：会话历史和用户画像存在平台私有库里；流程编排状态不可导出；工具鉴权与审批配置只能在控制台点击，不支持代码化。
规避锁定的做法，是把这三点在选型阶段就定下来。会话记录、任务状态、审计日志应存在企业自己的数据库；流程定义能够导出，至少在切换后可以重新导入；工具调用记录提供标准接口可以拉取。你可以在合同里写清楚：供应商需要配合做一次数据导出测试，并且提前给出迁移方案。
另一个容易被忽略的点：如果Agent已经和后台系统建立了许多权限关系，迁移时不只是搬代码，还要重建所有工具凭证。因此，凭证和密钥应由企业集中管理，不要把几百个凭据全部放进平台内置的钥匙串。
5. 避坑指南：稳定性、安全边界、可观测性和Agent评测
链路越长，故障越不像以前那样集中在模型层。以下几项都调试到位，才算进入生产可用范围。
稳定性：把超时、重试、幂等当成功能开发。 每个工具调用都应设置超时上限；失败后按类型决定重试或者降级。涉及创建订单、修改账户这类操作，要提供幂等键，防止Agent因网络超时重复提交。普通API可以允许超时重试，写操作必须做完这个检查才能上线。
安全边界：把网页、文档和工具返回值当成不可信输入。 提示注入攻击会利用外部文本让Agent执行非预期动作。系统指令中要明确外部内容只是参考，禁止触发工具；对敏感操作做二次授权；每次执行写操作都要留下审计事件。外部数据在传给模型前先做格式校验和长度限制，降低攻击面。
可观测性：日志要能回答“坏在哪一步”。 Agent每一次计划、工具调用、工具返回都需要记录，包括入参、出参、耗时和token消耗。错误处理逻辑也应当写入日志，才能区分是模型判断错，还是数据源不对，或是权限配置拦截。
评测体系：要分三层持续滚动。 评测集至少要有三份：一是黄金集，沉淀100个以上真实业务任务，每次更换模型或修改提示词后全量回归；二是失败集，把生产环境标记为“结果不对”的案例放进去，防止旧问题回归；三是生产灰度指标，观察任务完成率、平均工具调用次数和用户反馈。平均调用次数上升而完成率不变，通常说明模型开始“瞎试”。
从本文带走一个可执行动作：下一个Agent项目进入POC时，先在测试环境验证两件容易被跳过的工程项——写操作是否具备幂等能力、流程定义是否能够导出。这两个检查项过了，至少说明这个系统是照着生产环境设计的。