企业第一次做 Agent，常见起点是一个模型、几个工具和一段循环代码。Demo 很快能跑起来，但进入生产后会突然遇到另一组问题：任务跑到一半服务重启怎么办，用户身份如何传进工具，多个 Agent 能否共享状态，错误动作如何拦截，谁批准新工具上线，成本和质量怎样持续观察？这些问题并不属于同一层产品。
四层技术栈不要混着比较
第一层是 Agent SDK。OpenAI Agents SDK、Claude Agent SDK、Google ADK、Microsoft Agent Framework 等提供 Agent、工具、交接、护栏、会话或多智能体等代码原语。它们帮助开发者表达执行逻辑，但通常不会自动提供完整的企业控制面。
第二层是 编排框架。LangGraph 这类框架强调状态、图、分支、循环、检查点和人工中断。它适合长流程与可恢复任务，但身份、网络、资源隔离和组织级发布仍要另行解决。
第三层是 Agent Runtime。例如 Amazon Bedrock AgentCore 把 Runtime、Memory、Gateway、Identity、Policy、Observability 和 Evaluations 组织成模块化平台。Runtime 的价值不是让 Agent “更聪明”，而是让它在隔离、权限、弹性和审计条件下持续工作。
第四层是 Agent Builder。Dify、Coze Studio、阿里云百炼、百度千帆和 Microsoft Copilot Studio 让业务或产品团队通过界面组织模型、知识、工具和工作流。它们能降低构建门槛，但不会消除数据治理、插件安全、版本管理和生产运维。
先判断任务属于哪一类
固定顺序、规则明确的流程，优先使用传统工作流或确定性代码，只在需要理解和生成的位置调用模型。需要根据上下文选择工具、处理不完整信息的任务，才适合 Agent。长时间运行、跨多个系统并且需要等待人工审批的任务，才真正需要可恢复 Runtime。
多智能体也不是默认答案。一个协调者加多个专门 Agent 会增加交接错误、上下文成本和观测难度。若一个 Agent 加确定性节点能够完成，就不必为了架构新颖而拆分角色。
企业权限必须进入执行链
Agent 的权限不能等同于开发者配置的一把全局 API Key。更安全的模式是：用户以自己的身份发起任务，平台把用户或岗位身份传给 Agent，工具根据最小权限签发短时凭证，高风险动作触发明确审批，所有调用保留可查询的审计证据。
这也是最小权限在 Agent 时代的新含义：不仅限制“能访问哪些工具”，还要限制对哪些对象、在什么条件下、以谁的名义执行什么动作。模型的建议与系统的授权必须分离。
生产选型的九项清单
- 模型是否可替换，Prompt、工具协议和评测是否与供应商解耦；
- 会话、长期记忆和业务状态分别存在哪里，能否删除和导出；
- 长任务是否支持检查点、重试、幂等和人工恢复；
- 用户委托身份、服务身份和高风险审批如何实现；
- 工具是否经过注册、版本、权限、网络和供应链审查；
- 日志是否能串联模型调用、工具参数、执行结果与最终业务结果；
- 是否有任务级评测，而不只观察 token、延迟和错误码；
- 多租户、区域、加密、数据保留与合规要求能否满足；
- 从框架、Runtime 或 Builder 迁出的数据和工作流成本是多少。
推荐的落地顺序
先用一个真实、低风险且能量化结果的流程构建端到端垂直切片。第二步增加用户身份、审批和审计；第三步测试失败恢复与回退；第四步建立固定评测集；最后才比较不同 Runtime 的规模、成本和开发体验。
可以在本站的 Agent 与企业 AI 生态观察站 对照 OpenAI Agents SDK、Google ADK、Microsoft Agent Framework、LangGraph、AgentCore、Dify、Coze Studio、千帆与百炼。产品更新很快，具体能力应回到每个条目的官方来源复核。
最终应被企业长期保留的资产不是某一个框架，而是任务定义、工具契约、身份边界、评测集、审计证据和运营规则。只要这些资产保持独立，Runtime 才真正可替换。