有个问题最近被问得特别频繁：公司要做 Agent，到底该怎么起步？

问的人背景差别很大。有人已经在用 Coze 搭了几个内部小工具，想往核心业务推；有人手里有二十个工程师，纠结是买 Agentforce 还是自己用 LangGraph 写；还有人刚被老板按着头立项，预算批了，但连「Agent」和「聊天机器人」的区别都没想清楚。

这个问题之所以难回答，是因为它其实不是一个技术问题。它是一个「你愿意把多少责任留在自己手里」的问题。

我花了不少时间把市面上能走的路都过了一遍，最后把它们收敛成六条。这六条不是并列的六个产品，而是一条从「全部租出去」到「全部自己做」的连续光谱。这篇文章会按这个顺序讲，每条都配上流程图，让你大概知道它长什么样、谁在负责什么、什么情况下该选它。

先做一件不讨喜但必须做的事：把「Agent」这个词从营销话术里捞出来。

agent 这个词已经被用滥了

Gartner 给这种现象起了个名字，叫 agent washing——厂商把已有的聊天机器人、RPA 脚本、AI 助手重新贴个标签就叫 Agent，底下并没有新增什么能力。

这个标签污染是有代价的。Gartner 预测到 2027 年底，超过 40% 的 Agent 项目会被取消，理由排前三的是：商业价值不明确、成本持续上升、风险控制不足。注意，没有一条是「模型不够聪明」。Gartner 分析师 Anushree Verma 的说法更直白：现在大多数 Agent 项目都是被热度推动的早期实验，而且经常被用错地方。

另一组数据来自 MIT Media Lab：他们研究了 300 个公开的 AI 部署案例，发现 95% 的企业 AI 试点没有产生任何可衡量的财务回报。同时，Menlo Ventures 的调查发现一个很有意思的对照——从专业厂商买工具的团队，进生产环境的比例约 66%；自己从零造的，约 33%。

这两个数字合起来说明一件事：失败的原因不在技术选型，在于把 Agent 放进了一个自己都没写清楚的流程里。

所以我建议每个准备动手的团队先在内部回答一个问题：这个流程，当出现异常情况时，具体会怎么处理，写在纸上了吗？如果答案是「靠老张的经验」，那 Agent 不会修好这个洞，它只会以更快的速度和更大的规模把这个洞暴露出来。

好，前提说完了。下面是六条路线。

六条路线，一次看全

左边三条是「买」，右边三条是「造」。往右控制力越强，交付越慢，责任也越重。

先给一个可能有人不爱听但我认为重要的判断：大部分企业最终会是混合栈，而且这没什么不体面。通用流程买低代码平台或 SaaS 原生 Agent，少数真正构成差异化的环节才自研，中间用协议把两边接起来。2026 年真正跑通的企业，多数都是这个形态。

下面逐条讲。

路线一 · 低代码 / 零代码平台：把写代码换成连节点

这一类的代表是 Coze（扣子）、Dify、n8n，以及微软的 Copilot Studio。它们的共同点是把「写代码」换成了「拖节点」：意图路由、条件分支、循环、知识库检索，全部在画布上配。

上手速度是真的快。有实测对比过三家搭同一个电商客服 Agent 的耗时：Coze 约 6 分钟出活，准确率目测 85%；Dify 约 40 分钟，调完分块策略后到 91% 左右；n8n 花了近 2 小时，准确率 88%，但链路最灵活、能细到每个节点。这个量级的差异不是产品优劣，是定位差异——Coze 像点外卖，n8n 像乐高，Dify 像配好料的半成品菜。

三家人的路线也不一样：n8n 的立身之本是 400 多个预建节点覆盖主流 SaaS 的 API，Dify 的差异化在 RAG 的可配置性（父子分块、混合检索、重排），Coze 在国内的优势是插件生态和字节系渠道打通。GitHub 上的热度可以当参考：2026 年年中，Dify 约 9.2 万 star，n8n 约 6.8 万，Coze 国内版不开源。

优点很明确：天级别的上线速度，业务团队能自己维护，不用排研发的队。

缺点也一样明确，而且往往在六个月后才显现。平台的抽象是有天花板的——一旦出现跨多数据源的复杂条件分支，或者要接一个自研的老系统，画布就开始硌手。更麻烦的是迁移成本：逻辑锁在平台的配置里，换平台基本等于重做。我见过团队第一周搭出原型、上线三个月后发现新需求做不了、然后发现迁移比重写还贵。

所以这条路线适合的判断标准是：这个流程三五年内不会变，而且不需要接自研系统。

路线二 · 现有 SaaS 套件里的原生 Agent

如果你公司已经在用 Salesforce、ServiceNow、Microsoft 365 或者 UiPath，那其实不必新建一个 Agent——把开关打开就行。

这一类的落地数据是目前最扎实的。Salesforce 自己在财报电话会上讲过：Agentforce 在自家客服渠道上处理的服务量已经是人类客服的两倍，15 个月里自主处理了 400 万次客户咨询。PenFed 信用社部署了 76 个 Agent，通话时长降了 10%，事后整理工作降了 50%，光这一个 Agent 预计年省 160 万美元。UCLA Health 从零到上线用了八个月，现在患者查医生、查临床试验不用打电话了。

ServiceNow 那边也类似：它自己的 L1 服务台 AI 处理 IT 工单比人快 99%，公司内部超过 90% 的员工 IT 请求由它自动处理。Bell Canada 部署后客户响应时间改善 25%，Honeywell 的 AI 助手 “Red” 干掉了大部分服务台对话。微软的说法是 Copilot Studio 上有 16 万家组织在跑 40 多万个自定义 Agent。

这条路线最大的好处是「同源」。客户数据、工单对象、字段权限、审批流，本来就在平台里，不用重新对接一遍；Agent 也沿用既有的角色权限体系行动，安全评审少一轮。而且 60% 以上的 Agentforce 订单来自老客户扩购——这说明它确实是在存量场景里被验证过的。

代价是绑定。你的 Agent 能力上限，约等于这家厂商产品线的上限。想在一个厂商的三个产品之间做点花活，通常做不到。

另一个容易被忽略的坑：这条路线会逼着你把数据模型理顺。脏数据会让 Agent 的每一步推理都错，而且它错得很有说服力。Salesforce 那套体系讲究数据模型先治理、指令要让「一个完全不了解你公司的人也能听懂」，这不是空话——有金融科技公司就是先花时间治理数据模型，再把指令重写一遍，最后拿到了首日 67% 的会话覆盖、峰值 85% 的分流率。

路线三 · 垂直场景的 Agent 产品

这条路线本质上不是买工具，是买结果。厂商的实施团队来做，你按「成功解决」结算。

客服用最多的两家是 Sierra 和 Decagon。Sierra 由 Bret Taylor（前 Salesforce 联席 CEO）创立，2026 年 5 月融资后估值约 158 亿美元，累计融资约 16 亿美元，客户里有 40% 以上的 Fortune 50。Decagon 估值 45 亿美元，客户偏中端 SaaS，像 Notion、Duolingo、Chime。

真正值得关注的是定价模式的转向。整个行业正在从「按座位收费」转向「按结果收费」：Sierra 约 90% 的收入来自按成功解决计费，单价约 1.50 美元一次；Intercom 的 Fin 是 0.99 美元；而 Agentforce 和 Decagon 主要按对话收费（不管有没有解决）。这两种模式对客户的意义完全不同——按解决收费意味着厂商的利益和你的利益是一边的，你不需要为「Agent 聊了半天没解决」付钱。有分析直接点出 Decagon 的模式是「按努力收费」，Sierra 是「按结果收费」。

实施这件事上，有个数字厂商宣传里最不爱提：无论是哪家，部署初期都需要 30—60 小时的内部投入。定义工作流、清洗知识库、对接 CRM 和订单系统、约定人工兜底的边界。「开箱即用」在没有干净历史数据的前提下基本是营销语言。

适合谁：有明确的高频长尾场景（客服、对账、文档审阅）、历史数据质量还行、且愿意接受对某个流程失去部分控制权。

不适合谁：场景特别、问题高度长尾、或者你的流程本身就是竞争优势。这种情况下把流程交给外部产品，等于把差异化也交出去了。

从「买」到「造」，真正的分野在哪一层

讲完三条「买」的路，转向前先说清一件事：所谓自研，从来不是「做不做」的二选一，而是「你负责到第几层」。

把 Agent 系统拆成三层看：

第三层是 Harness 层——运行时、会话状态、代码沙箱、工具网关、身份凭据、审计和灰度。这一层决定了你的 Agent 能不能跑一整夜、能不能扛住重启、出事能不能复盘。

第二层是编排层——Agent 循环、工具调用、状态图、条件分支、子 Agent、人工中断与恢复。这一层决定了你的业务流程能不能被准确表达。

第一层是模型层——推理能力的来源。这一层已经高度商品化，换供应商的成本从数月降到了数周，它不再是护城河。

看清楚这张图，六条路线的差别就一目了然了：路线一、二、三是把三层全部租出去；路线四把第三层租出去、前两层自己做；路线五三层都自己做但用了现成的库；路线六连那层库也要自己写。

下面三条「造」的路，请对照着这张图看。

路线四 · 云平台上的托管 Agent 运行时

这是 2026 年增长最明显的一类，也是最被低估的一类。它的定位很精确：代码是你的，运维是云的。

AWS 的动作最典型。AgentCore 在 2026 年 4 月底正式 GA，8 月 6 日又上线了 runtime instances，把单会话时长从 microVM 的 8 小时拉到 14 天，支持 GPU 实例，多个 Agent 还能共享同一台机器和同一个文件系统。计费是 EC2 按需价加 12% 管理费（GPU 系列 7.8%）。

这个计费变化值得单独说一句。从「按 token 计费」转向「按持有机器的小时数计费」，意味着成本结构变了：空转的 Agent 也变成一笔账。一个等着人类审批的 Agent，可能在后台占着一台机器等着。这是企业还没建模过的成本形态。

工具接入走 AWS 的 Agent Registry 和 Gateway，权限走 IAM，执行轨迹直接写进 CloudWatch，还有 A/B 流量切分做灰度。Google 那边是 Vertex AI Agent Engine，runtime 定价每 vCPU 小时 0.0864 美元；国内的对应物是阿里云百炼、腾讯云 ADP、火山引擎 HiAgent 这类平台。

微软的玩法又不太一样。Agent 365 在 2026 年 5 月上线，15 美元/用户/月，做的是「Agent 舰队」的治理：身份、生命周期、审计、安全监控。它不管你的 Agent 怎么造，只管造出来之后谁负责。

UiPath 提供了一个很好的混合栈样本：保险理赔场景里，IXP Agent 从共享邮箱抽取理赔字段，Maestro 跑理赔裁决 Agent，遇到高额或异常案件就通过 MCP 调用一个用 LangGraph 写在 Microsoft Foundry 上的风险 Agent，判断超过阈值就转到 Teams 里人工复核。整条流程里，UiPath、Foundry、Copilot Studio、Teams 各干一部分，靠编排层捏成一个系统。

这条路线为什么值得认真考虑：它把自研里最不值钱的部分（运维、扩缩容、会话持久化）外包出去，把最值钱的部分（业务逻辑、状态模型）留在自己手里。代码还是你的，随时能搬到别处跑，不存在平台抽象锁死的问题。

代价：你仍然要自己写编排逻辑，这意味着第二层的能力要求一点没降。它解决不了「团队不懂 Agent 架构」这件事。

路线五 · 开源代码框架自建

这是目前技术团队最主流的选择。典型投入是 2—4 名工程师、2—4 个月。

2026 年这一层的格局已经基本稳定：

框架	什么情况下选它	要注意什么
LangGraph	流程有环、需要可审计的长流程、需要人工中断与恢复	简单场景写起来啰嗦；checkpoint 不等于 durable execution
MS Agent Framework	微软栈、.NET 团队、需要 LTS 承诺	社区最小；隐含 Azure 依赖
OpenAI Agents SDK	主用 OpenAI 模型、需要沙箱代码执行、要极致简单的 API 面	模型可移植性差；仍是 pre-1.0，版本要钉住
Google ADK	Google Cloud、需要图式确定性、需要 Go / Java / Kotlin	偏向 Gemini 优化
CrewAI	工作可以拆成清晰的角色分工，要快速验证多 Agent 有没有用	角色模型不适合要求每步可审计的场景
AWS Strands	在 AWS 上，想最快从零到一个能跑的 Agent	编排引擎相对薄

几个重要变化：LangGraph 在 2025 年 10 月发布 1.0，Uber、LinkedIn、JP Morgan 都在用，IBM 在 2026 年 5 月给 watsonx Orchestrate 加了 LangGraph Agent 导入；微软的 Agent Framework 在 2026 年 4 月 3 日 GA，同时把 AutoGen 和 Semantic Kernel 推进了维护模式——如果你还在 AutoGen 上，迁移应该排进未来两个季度的计划；OpenAI 的 Agents SDK 在 2026 年 4 月做了一次架构调整，把 harness 和 sandbox 拆开，同一份 Agent 定义在本地和各家托管沙箱（Modal、E2B、Cloudflare、Daytona 等）之间可以不改代码地跑。

但我想说的是另一件事，也是我认为这条路线最容易失败的地方。

框架只覆盖了整个系统价值的 20%。剩下 80% 在评测、trace、成本看板、提示词版本管理、人工审核队列这些不性感的地方。而大多数团队的时间分配是反过来的：花六周 A/B 两个框架，花零周搭评测。

一个没有评测的 Agent 不是产品，是 demo。这句话值得写在每个 Agent 项目的墙上。选框架这个动作本身，远没有「建一套能告诉你 Agent 有没有变好」的机制重要。

Anthropic 自己给的建议也值得放在这里：能从最简单的方案开始就别上复杂方案。他们推荐的判断顺序是先看流程是否可预测——可预测就用 workflow，用固定的代码路径；只有确实无法预先确定步骤时才上 Agent 循环。即便是复杂场景，也该先试单次调好工具的模型调用，而不是一上来就搞多 Agent。

路线六 · 不套框架，直接调 API 从零自研

最贵的一条，也是唯一一条在架构上不受任何约束的路。

它要写的东西包括但不限于：Agent 主循环、工具接口设计、上下文管理与长任务记忆、代码沙箱与权限模型、错误恢复、模型换代应对。Anthropic 把工具设计这件事单独提出来叫 Agent-Computer Interface（ACI）——工具的命名、参数、示例、错误信息措辞，对最终效果的影响比提示词技巧更大。他们在 SWE-bench 上的经验是：先优化工具，再优化提示词。

说实话，我建议绝大多数团队不要走这条。判断标准其实只有一个问题：

你造出来的这个东西，18 个月后还是差异化壁垒，还是维护负担？

如果是前者，自研。如果是后者，别造。而根据我看到的情况，多数团队的真实答案是后者——只是它们往往在投入半年、烧掉两个资深工程师之后才承认这一点。

有个反面案例很能说明问题。Gartner 和 MIT 的研究者做过一次受控测试，场景是供应商发票错误处理，用一个年处理 750 亿美元发票的企业的真实数据，拿同一组 44 张发票测四种模型配置。结果是：能力最强、成本最高的配置反而表现最差。结论不是「别用最强模型」，而是「按任务匹配模型，并且要测组件组合，而不是逐个单独测」。

所有路线共用的地基：MCP 与 A2A

不管你选哪条路，都会撞上这两个协议。它们不是竞争关系，是一个纵、一个横。

MCP（Model Context Protocol） 管的是 Agent 到工具这一层。2024 年 11 月由 Anthropic 提出，现在 ChatGPT、Cursor、Gemini、Microsoft Copilot、VS Code 都支持。规模上：2026 年 3 月 SDK 月下载量约 9,700 万次；到 2026 年 7 月，约 78% 的企业 AI 团队已有 MCP 支持的 Agent 进生产；41% 的 Fortune 500 在跑 MCP server。

A2A（Agent2Agent） 管的是 Agent 到 Agent 这一层。Google 2025 年 4 月提出，让一个 Agent 能发现另一个 Agent 会什么（通过机器可读的 Agent Card）并把任务委派过去，哪怕两边跑在不同框架、不同厂商、不同公司。2026 年 4 月，A2A v1.0 稳定版上线，超过 150 家组织进入生产采用，覆盖供应链、金融、保险、IT 运维。

最关键的一点是治理归属：MCP 和 A2A 现在都在 Linux Foundation 下托管。Anthropic 在 2025 年 12 月把 MCP 捐给了 Linux Foundation 新设的 Agentic AI Foundation，OpenAI、Google、Microsoft、AWS 都是白金成员；Google 更早在 2025 年 6 月就把 A2A 捐了出去。当协议属于某一家厂商时，采用它是一种战略依赖；当它属于中立基金会时，采用它只是正常的工程决策。

所以选型时多问一句：它支持 MCP 吗？支持 MCP 意味着你的工具资产可以跟着你走——换平台、换框架、换云都不用重写接入层。这是唯一一件能让你在未来少交学费的事。

怎么选：三个问题，四个出口

顺序很重要。先判断该不该自己造，再判断用什么造。

问题一：这件事，18 个月后还是我们的差异化壁垒吗？不是 → 走路线一、二、三，先买。

问题二：团队有 2 名以上资深 AI 工程师，且能等 2 个月以上吗？没有 → 走路线四，逻辑自己写、运维交给云。

问题三：已经在某朵云或某个框架上做了深度投资吗？是 → 走路线五，跟着既有栈选框架；都不是且要极致控制 → 路线六。

不管你落在哪个出口，还有一条通用建议排在所有建议之前：先确认流程本身是清楚的。Gartner 那 40% 的项目失败，主因是价值不明确、成本失控、治理不足——没有一条是模型不够好。

另外，Gartner 还有一条预测值得做治理的同学留意：到 2027 年，40% 的企业会因为治理缺口而降级或退役自治 Agent，而且这些缺口往往是在生产事故之后才被发现的。他们的分析师特别提醒，企业对 Agent 治理不能是二元的——要么全锁死、要么全信任，这是失败的根源。Agent 运行在不同的自治等级、跨越不同的信任边界，治理也该是分级的。

几条不写进宣传材料的实话

第一，规模化的失败点几乎都在数据上。有调查显示 52% 的组织把数据质量列为最大阻碍。Agent 的推理能力不是瓶颈，喂给它的上下文才是。

第二，「Agent」和「自动化」的界线常被故意模糊。如果一个流程用确定性代码或工作流引擎就能做，那就不该上 Agent。Anthropic 的措辞很克制：能用 workflow 就用 workflow，只有在无法预先确定步骤时才上 Agent 循环。Gartner 也提过类似的判断——很多 Agent 项目是「被错误地应用」的。

第三，警惕只看「时间节省」的价值论证。Gartner 分析师的说法是：如果我们还在谈时间节省和个人生产力，那对客户投入的规模来说是站不住脚的。Agent 的价值必须绑在具体的业务结果上——财务、人力、安全、运营的某个可衡量指标。

第四，成本模型要重算。Agent 的消耗方式和传统软件完全不同：一次任务会触发多轮推理、工具调用、重试和校验。用 GenAI 的 token 单价去估 Agent 的成本，一定会低估。当编排层、治理层、多个 Agent 叠上去之后，成本曲线是指数上升的。

第五，先小再大，而且小要小得聪明。有调查显示，约 79% 的企业声称已经采用 Agent，但只有约 11% 在生产环境规模化运行。这两组数字之间的落差，就是本文全部内容的意义。挑一个高频、有明确正确答案、能算出数字的任务做四周试点，保留人工审边缘案例，然后再谈扩张。

参考链接

• Anthropic，Building Effective Agents：https://www.anthropic.com/engineering/building-effective-agents
• Model Context Protocol 官方文档：https://modelcontextprotocol.io
• A2A Protocol（Linux Foundation）：https://a2a-protocol.org
• AWS Bedrock AgentCore 文档：https://docs.aws.amazon.com/bedrock-agentcore/
• Salesforce Agentforce 客户案例：https://www.salesforce.com/customer-stories/
• LangGraph 文档：https://langchain-ai.github.io/langgraph/
• Microsoft Agent Framework 概览：https://learn.microsoft.com/en-us/agent-framework/
• Google Agent Development Kit（ADK）：https://google.github.io/adk-docs/
• OpenAI Agents SDK：https://openai.github.io/openai-agents-python/
• Gartner 关于 Agent 治理的新闻稿：https://www.gartner.com/en/newsroom

本文配图均为本人绘制，原始 SVG 与高清 PNG 可在文章目录内取用。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。