经常看到一个问题：
“我们要做 Agent，到底选 OpenAI / Anthropic / Google / Microsoft 哪家？”

说实话，这个问法很容易把团队带沟里。因为真正决定成败的，经常不是“哪家模型更强”，而是下面这些更朴素的事：

• 你要交付的是一段代码（框架），还是一个平台（低代码/托管）？
• 你的 Agent 需要连多少系统？权限怎么给？出事能不能追溯？
• 你们的工程栈是 Python / .NET / Java，还是全家桶云服务？

这篇我不打“星级榜”，也不做宣传页复读机。我们按落地思路，把四家放到同一张“工程桌面”上看清楚。

---

1）先把 Agent 拆开：你其实在选一整套“交付链路”

如果你只把 Agent 理解成“会调用工具的 LLM”，你会在第二周就撞上墙。

我更喜欢把 Agent 拆成 5 个零件（你可以用它做选型 checklist）：

1. 模型（Model）：推理、对话、工具调用能力。
2. 工具接入（Tools）：怎么把 GitHub/Jira/DB/内部 API 接给它用。
3. 状态（State）：多轮任务怎么记住“做到哪一步了”，失败了怎么恢复。
4. 观测（Tracing/Logging）：出错能不能定位，能不能复盘每一步做了什么。
5. 权限与治理（Security/Governance）：最小权限、审批点、审计、合规边界。

四大厂商的差异，往往体现在 2~5 这几项，而不是 1。

---

2）四家到底差在哪：落地时最常见的 8 个问题

下面这 8 个问题，是我做 POC/上线时最常被问到的（也是最容易踩坑的）。

2.1 你要的是“框架”还是“平台”？

• OpenAI：偏“框架/SDK”，你写代码、自己接系统、自己负责运维与治理。
• Anthropic：更像“模型 + 工具协议生态（MCP）+ 一些独特交互能力”，你可以自建，也可以接入现成生态。
• Google：更偏“企业平台”，很多能力被收进云产品里，适合要快、要管控、要企业集成的团队。
• Microsoft：明显“双轨”，开发者侧（开源框架/SDK）+ 企业侧（协作套件/低代码平台）。

一句话：
你越想“少写代码快上线”，越会靠近平台；你越想“可控可改能深度定制”，越会靠近框架。

2.2 工具怎么接？有没有“可迁移”的接法？

落地时工具接入经常是工时大头：鉴权、限流、幂等、错误码、审计、权限。

• OpenAI：更像“把工具当函数/能力”，框架把工具调用串起来，开发体验顺。
• Anthropic：MCP 这一点很关键，它把“工具接入”抽成协议，天然更接近“可迁移”。
• Google：企业连接器与云资源整合做得深，尤其当你的数据就在 GCP。
• Microsoft：如果你的工作流天然在 M365（Outlook/Teams/SharePoint…），它的集成优势会非常现实。

我自己的偏好是：
内部工具先做成“协议/网关层”，上层 Agent 框架随时可换。

2.3 状态怎么管？失败怎么恢复？

真正上线后，你会发现任务不是“一问一答”，而是：
“查三套系统 -> 写回工单 -> 等审批 -> 再推进下一步”。

因此你要问清楚：

• 是否天然支持“会话/任务状态”？
• 是否容易做“断点续跑/重试/幂等”？
• 是否支持“人在回路”（审批点）？

不同方案差异很大：有的你得自己写状态机，有的更像给你一套管控壳。

2.4 观测怎么做？出了问题能不能解释清楚？

Agent 出问题时最要命的不是“它错了”，而是：
“它怎么走到这一步的？是谁让它这么干的？它当时看到了什么信息？”

选型时至少要能做到：

• 每一次工具调用可追踪（输入/输出/耗时/错误）
• 每一次决策可回放（当时上下文、当时策略）
• 能落到你们现有监控体系里（日志平台/APM/告警）

2.5 权限怎么给？怎么防止“越权操作”？

Agent 最危险的一句话不是“我不知道”，而是“我已经帮你做完了”。

你要把权限当成产品能力来设计：

• 工具白名单/参数白名单
• 风险分级（低风险自动执行，中风险异步审核，高风险必须人工确认）
• 审计日志（谁触发的、为什么触发、调用了什么）
• 预算与速率限制（防止循环调用把账单打爆）

2.6 企业合规与数据边界：你能不能接受“云上强绑定”？

很多团队最后不是技术上选不出来，而是卡在：

• 数据能不能出内网
• 日志能不能落地本地
• 权限审批能不能接你们现成系统
• 是否需要多地域/多租户隔离

这个维度上，“平台”一般更省事，“框架”一般更灵活。

2.7 你的工程语言栈是不是“主流受支持”的那一个？

这点经常被低估：同一套方案，Python 团队和 Java/.NET 团队的体验会差很多。

我建议你至少问一句：
“我们要维护这套东西两年，主力开发语言会不会变成负担？”

2.8 成本与可靠性：别只看 token 单价

上线后成本通常由三部分组成：

• 模型调用（token）
• 工具调用（外部 API、DB、搜索、爬取）
• 重试与失败（失败越多，隐性成本越高）

可靠性也是一样：不要只看模型“能不能答对”，更要看“工具链路失败时怎么兜底”。

---

3）我会怎么选：三种最常见的团队画像

下面不是标准答案，更像“我见过的常见走法”。

3.1 你是创业团队/小团队：要快验证、要能迭代

优先考虑“开发效率”和“可观测性”，别一开始就追求大而全平台。

典型做法：

• 先用框架把第一条业务链路跑通（有 tracing，有失败兜底）
• 工具层做成你自己的网关（后面可换模型/可换框架）
• 用一两条最赚钱/最省人工的流程做 ROI

3.2 你是大企业：权限、审计、合规优先级最高

大企业最怕的不是“慢一点”，而是“出了事说不清”。

典型做法：

• 先把权限/审批/审计打通（再谈多 Agent 协作）
• 先选“低风险场景”上线（客服分流、工单辅助、知识检索）
• 先做“人机协作”，逐步放权

3.3 你天然绑定某个生态（GCP 或 M365）

如果你的数据、账号体系、协作流都在同一家生态里，强绑定未必是坏事，甚至能省你半年集成工时。

但建议保留一条后路：
把模型调用层抽象出来，把工具层抽象出来。

---

4）一个“可迁移”的最小接入模板：Python 版（建议你们 POC 直接抄）

下面这段 Python 代码的目的只有一个：
把“模型厂商”从业务代码里拔出来。

你只需要换 baseUrl 和 apiKey，就能在不同 OpenAI 兼容网关/服务之间迁移；
工具与权限也可以独立演进，不跟某个 SDK 深度绑定。

4.1 一个最小的 ModelClient 抽象（OpenAI 兼容）

from __future__ import annotations

from dataclasses import dataclass
from typing import List, Dict, Any, Protocol

import requests


@dataclass(frozen=True)
class ChatMessage:
    role: str
    content: str


class ModelClient(Protocol):
    def chat(self, *, model: str, messages: List[ChatMessage], temperature: float = 0.2) -> str: ...


class OpenAICompatibleClient:
    """
    适配 OpenAI 兼容接口：只要换 base_url，就能切到不同网关/服务（前提：兼容 /v1/chat/completions）。
    """

    def __init__(self, base_url: str, api_key: str, timeout: float = 30.0):
        self.base_url = base_url.rstrip("/")
        self.api_key = api_key
        self.timeout = timeout

    def chat(self, *, model: str, messages: List[ChatMessage], temperature: float = 0.2) -> str:
        url = f"{self.base_url}/chat/completions"
        headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json",
        }
        payload: Dict[str, Any] = {
            "model": model,
            "messages": [{"role": m.role, "content": m.content} for m in messages],
            "temperature": temperature,
        }
        resp = requests.post(url, headers=headers, json=payload, timeout=self.timeout)
        resp.raise_for_status()
        data = resp.json()
        return data["choices"][0]["message"]["content"]

4.2 工具层：先把“能做什么”白名单化

from typing import Callable


ToolFn = Callable[[dict], str]


class ToolRegistry:
    def __init__(self, allowed: dict[str, ToolFn]):
        self._allowed = allowed

    def get(self, name: str) -> ToolFn:
        if name not in self._allowed:
            raise ValueError(f"tool not allowed: {name}")
        return self._allowed[name]

你会发现：
一旦你把“模型调用”和“工具能力”分开，选型就不再是“押注某一家”，而是“替换一个实现类”。

---

5）写在最后：别被“产品名”带节奏，拿 checklist 做你自己的答案

如果你只想带走一件事：
四大厂商的差异不是宣传页上的功能点，而是你能不能把工具、状态、观测、权限这条链路做稳。

你可以把这篇当成一个选型起点：
拿着第 2 节的 8 个问题，去问你们的研发、运维、安全、业务同学。
答案自然会把你推向“框架派”还是“平台派”，也会把四家拉开差距。