企业级 Agent 开源选型：决策树、四段可抄代码、真实成本、五类安全红线
【摘要】 选错框架最多浪费三周，忽略部署依赖、成本和许可证，会浪费三个月。选型本质上不是选框架，是选你愿意承担哪几种成本：集成成本、运维成本、许可成本、迁移成本。四个都算过一遍，答案自己就出来了。一 四个问题定位，别按名单选Q1 流程里有几个"必须人审"的节点？0 个 → 不需要重型编排，OpenAI Agents SDK 或 Pydantic AI 起步更快。1–2 个 → LangGraph 的 ...
0 个 → 不需要重型编排，OpenAI Agents SDK 或 Pydantic AI 起步更快。
1–2 个 → LangGraph 的 interrupt 够用。
≥3 个 → 别自己写审批，直接上 HumanLayer 这类审批基建，否则你会写出四个版本的自研工单。
< 30 秒 → 内存状态即可。
30 秒–5 分钟 → 必须 checkpoint（LangGraph + Postgres）。
> 5 分钟或跨系统多阶段 → 需要持久化执行引擎（Temporal），自己写状态机一定会漏分支。
.NET / Azure → Microsoft Agent Framework（1.0，MIT，双运行时）。
Python → LangGraph 或 OpenAI Agents SDK。
Java → Spring AI Alibaba（11,047 ★，Apache-2.0），别硬套 Python 方案。
私有化 → 许可风险低，但运维成本全担。
SaaS → Dify 禁多租户、n8n 禁托管转售，这两条会直接卡死商业模式。
缺口：图要你自己设计，没有"默认正确"的拓扑；可观测靠外部（LangSmith 或 Langfuse）；前端要自己写。上手曲线是五个里最陡的。
什么时候值：流程有明确分支、需要断点续跑、需要人审插队。
缺口：1.0 于 2026-04-02 才 GA，中文实战案例少；Python 侧生态成熟度弱于 .NET；国内中间件（钉钉/企微/用友）适配要自己写。
什么时候值：.NET 团队、Azure 环境、要进 M365。
缺口：单进程模型，分布式与长流程要自己补；tracing 默认送 OpenAI 平台，私有化要换。
什么时候值：单业务线快速跑通，团队小、要最少抽象。
缺口：确定性流程控制弱、状态持久化靠外部。角色扮演很好演示，但审批、重试、幂等这些企业必需项要另补。
什么时候值：内容生产、研究报告这类"过程不要求确定"的任务。
缺口：海外工具生态与第三方集成少，社区主要中文。
什么时候值：国内模型为主、要中文文档、看重多智能体消息机制。
- model_name: gpt-5
litellm_params:
model: azure/gpt-5
api_base: os.environ/AZ_BASE
api_key: os.environ/AZ_KEY
- model_name: qwen-max
litellm_params:
model: dashscope/qwen-max
api_key: os.environ/DS_KEY
litellm_settings:
fallbacks: [{"gpt-5": ["qwen-max"]}]
cache: true
cache_params: {type: redis, ttl: 3600}
router_settings:
routing_strategy: usage-based-routing-v2
num_retries: 2
timeout: 600
fallbacks 是国内的刚需（单一供应商限流时能自动切）；usage-based-routing 让便宜模型承接简单请求，实测能砍掉三到五成成本。虚拟 key 用 /key/generate 按业务线发，带 max_budget，成本才能归属到部门。from langgraph.checkpoint.postgres import \
PostgresSaver
from langgraph.types import interrupt, Command
def approve(state):
d = interrupt({"act": "更新工单",
"payload": state["draft"]})
if d["approved"]:
return {"status": "done"}
return {"status": "rejected"}
with PostgresSaver.from_conn_string(
DSN) as cp:
cp.setup()
g = StateGraph(State)
g.add_node("approve", approve)
app = g.compile(checkpointer=cp)
cfg = {"configurable":
{"thread_id": "t-001"}}
app.invoke({"draft": d}, cfg)
app.invoke(Command(
resume={"approved": True}), cfg)
providers:
- openai:gpt-5
- litellm:qwen-max
tests:
- vars: {q: "3号线停机原因"}
assert:
- type: contains
value: "报警"
- type: not-contains
value: "猜测"
- vars: {q: "明天天气怎么样"}
assert:
- type: llm-rubric
value: 应说明不在职责范围
hl = HumanLayer()
@hl.require_approval(
channel="slack")
def update_ticket(tid: str,
fields: dict):
return crm.update(tid, fields)
Web + Worker（两个容器）+ Postgres + ClickHouse + Redis/Valkey + S3/MinIO
ClickHouse 是硬依赖，按官方架构，trace/observation/score 全存在它里面。这就是"装到一半发现要多一台 16G 机器"的原因。最小可用约 8 核 28G；ClickHouse 单机 4C16G 起。
好处是：trace 先落 S3 再入 ClickHouse，数据库挂了几分钟不丢数据。
api + worker + web + Postgres + Redis + 向量库 + sandbox
sandbox 必须独立部署（跑用户代码节点），不能和省事塞进同一个容器——这是安全边界，不是性能优化。
前端 + 历史 + 匹配 + 内部 worker + 持久层（Cassandra 或 Postgres）
只有"确实需要跨天续跑"的流程才上，否则用 LangGraph checkpoint 就够。别为了架构完备给自己加一个分布式系统。
显存 ≈ 参数量 × 精度字节 × 1.2（KV cache 与碎片）
32B FP16 → 64G × 1.2 ≈ 77G，单张 80G 很紧，实用是 2 张或改 INT8（约 38G）。
70B FP16 → 140G × 1.2 ≈ 168G，最少 3 张 80G，通常是 4 张。
n = 轮数
S = 系统提示词长度
Δ = 每轮新增 token
= 30,000 + 36,000
= 66,000 token
而单次问答只要 3,800 token。
放大 17 倍。
2. 轮数是平方项。把 10 轮压到 7 轮，输入从 66,000 降到 37,800（−43%）。减少"再查一次"的冲动，比任何缓存都省。
3. prompt caching 只对 S 有用。命中缓存的部分通常按 10% 计价，上面那 30,000 能压到约 3,000 的量级，整体省约四成。但它不会帮你省 Δ——所以"上下文管理"才是真功夫。
恶意指令藏在工具描述里——模型看得到，用户看不到。MCPTox 基准对真实 MCP 服务器和主流模型测试，攻击成功率超过 60%，涉及 o1-mini、DeepSeek-R1 等生产在用模型。已有确认案例：postmark-mcp 冒充合法项目。
放一个名字极度相似的合法工具在旁边，诱导模型选错；或者工具第一次审核时是干净的，更新后变坏。
对策只有一条：锁版本 + 变更需重新审核，别用 latest。
MCP 服务器返回的文件内容、数据库行、网页正文里若含指令，模型可能当命令执行——因为宿主信任"这个服务器是数据源"。
对策：返回内容与指令分区隔离，结构化包装，不让原始文本直接进指令位。
2025 年有 24,008 个密钥被泄露在 MCP 配置文件里。共享 admin token 是最常见的写法，也是最贵的写法。
对策：读写分离作用域、短时效 token、日志脱敏。
2026 年 1–2 月的 ClawHavoc 行动向 OpenClaw 市场投放了 1,200 个恶意工具；CVE-2026-25253 是第一个分配给 Agent 系统的 CVE（技能运行时远程代码执行）。
对策：白名单 + 容器隔离 + 不共享文件系统和凭据。
Semantic Kernel → Agent Framework：官方提供迁移指南，v1.x 至少维护一年，可以按需渐进。
Dify → 自研：最难。DSL 和工作流是平台私有格式，业务方搭得越多，迁出成本越高。用之前就要接受"这部分是沉没成本"。
LangGraph → 其他：图要重画，但节点里的业务代码大多可复用（如果你把业务逻辑和编排分开写了）。这个"分开写"的习惯，决定了你未来的迁移成本。
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）