企业级 Agent 建设实践：为什么企业场景更容易收敛，以及怎么做
一个广告投放 Agent 从 v0.1 到 v0.4 的架构演进复盘，提炼出可迁移的企业级 Agent 建设方法论
做了几个月的 Ad Agent——一个用 AI 驱动广告投放决策和执行的系统——我对企业级 Agent 的理解从“让 LLM 调 API”彻底转变为“在确定性管道里嵌入有限智能”。
这篇文章不是技术教程，而是一系列实践判断：为谁建、在哪建、怎么建。如果你正在考虑在企业场景中落地 AI Agent，这些弯路和选择或许能帮你省几个月。
一、为谁而建：Agent 的价值不是“自动化”，是“决策密度”
很多团队启动 Agent 项目的出发点是“自动化人工操作”。这个起点没有错，但它低估了 Agent 真正的价值锚点。
软件 vs Agent：从劳力外包到智力外包
过去十年的 2B 软件本质是劳力外包——SaaS 替你执行流程、存储数据、生成报表。它降低了操作成本，但没有降低决策成本。一个优化师用了最好的投放平台，仍然需要自己判断“这个 campaign 该不该暂停”。
Agent 不一样。它的核心价值是在单位时间内处理更多决策——不是“帮你点按钮”，而是“帮你想清楚该不该点”。
| 维度 | 传统 SaaS | AI Agent |
|---|---|---|
| 替代物 | 人工操作 | 人工判断 |
| 价值单位 | 功能覆盖度 | 决策密度（每小时处理多少决策点） |
| 天花板 | 流程效率 | 策略质量 |
| 用户心态 | “帮我做” | “帮我想，然后我决定（或你替我做）” |
“为谁建”的三个维度
- 他的决策频率有多高？ — 广告优化师每天面对几百个 campaign × 几十个指标 = 数千决策点。这是 Agent 的最佳土壤。如果一个岗位每周只做 3 个决策，不需要 Agent。
- 他的决策有多结构化？ — “这个 campaign CPI 超标 20%，该不该暂停”是结构化决策，Agent 能胜任。“这个品牌 slogan 好不好”是非结构化判断，Agent 能辅助但不能替代。
- 错误决策的代价是什么？ — 暂停一个广告 campaign 的成本是可量化的（损失几小时曝光）；给客户发了一封错误的邮件可能丢掉这个客户。代价越可量化、越可逆，Agent 越适合介入。
实践判断：不要因为 LLM 什么都“能做”就什么都做。先找到“高频 × 结构化 × 可逆”的决策交叉点，把 Agent 钉在那里。
二、在哪里建：Agent 难度光谱——对手方决定了你的架构复杂度
我在做 Ad Agent 时发现了一个判断 Agent 难度的简单框架：不是看你的 Agent 有多聪明，而是看它面对的“对手方”有多确定。
Agent 难度光谱
1234567891011
容易 ◄──────────────────────────────────► 难
Platform-Facing System-Facing Human-Facing
广告投放 Agent 数据分析 Agent 客户触达 Agent
面对平台 API 面对数据库 面对真人用户
──────────── ────────────── ──────────────
对手方：确定性系统 对手方：半确定性 对手方：不确定性
API 有文档 数据有 Schema 人有情绪、偏好、节奏
错了可回滚 错了可重跑 错了可能失去用户
反馈是数字 反馈是指标 反馈是沉默或拉黑
Schema→API 映射 SQL→结果 映射 NL→NL 没有锚点
为什么企业场景更容易收敛？
因为企业操作的大多数对手方是系统，不是人。
- 投放优化的对手方是 Meta / Google / TikTok 的 API — 接口文档完整，状态可查，操作可逆
- 数据分析的对手方是数据库 — Schema 明确，SQL 可验证，结果可重跑
- 财务对账的对手方是 ERP 系统 — 字段确定，规则固定
- DevOps 的对手方是 CI/CD 管线 — 状态机清晰，日志完整
而 C 端 Agent 的对手方是人——人的反馈是模糊的（“还行吧”），人的状态是不可见的（在忙还是在无聊？），人的容错率极低（一次糟糕的推荐就取关了）。
实践判断：企业级 Agent 的第一个项目，选 Platform-Facing 场景。API 文档 = 你的训练数据，状态码 = 你的反馈信号，回滚机制 = 你的安全网。不要上来就做“自动写邮件给客户”这种 Human-Facing 场景。
平台 API 本身也有“确定性分层”
即使是 Platform-Facing，也不是所有功能都能自动化。以广告平台为例：
| 等级 | 含义 | 对 Agent 的影响 |
|---|---|---|
| L1 · UI Only | API 不支持，只能在广告后台手动操作 | Agent 无法触及，需要人工兜底 |
| L2 · API 有，生态没跟上 | Marketing API 开放，但第三方工具未集成 | 差异化机会——自建 Agent 能覆盖 |
| L3 · 生态已覆盖 | API 开放，主流工具已集成 | 无差异化空间，Agent 做不了比现有工具更多 |
Ad Agent 最有价值的区域恰好是 L2——平台 API 已经支持，但聚合工具还没跟上。这是 Agent 的“蓝海区”。
三、怎么建：两次翻译、Schema 居中、分级信任
这是 Ad Agent 架构演进中沉淀下来的核心方法论。我把它拆成三层：意图理解、规范约束、执行监控。
3.1 意图理解：NL → Schema（第一次翻译）
Agent 的第一步是理解用户到底想干什么。关键设计：不要让 LLM 直接调 API。
123456789101112131415
用户说: "把 CPI 超过 2 美元的 campaign 都暂停"
│
▼ 第一次翻译（LLM 负责）
Schema JSON:
{
"action": "pause_campaign",
"filter": { "metric": "cpi", "operator": ">", "value": 2.0 },
"scope": "all_active_campaigns",
"confidence": 0.92
}
│
▼ 第二次翻译（确定性代码，零幻觉）
Meta API: POST /campaigns/{id}/status {"status": "PAUSED"}
Google API: mutate(campaign_operation: PAUSE)
...
“两次翻译、Schema 居中”是整个架构的核心。LLM 只负责第一次翻译（理解意图、填充 Schema），第二次翻译（Schema→API 调用）是确定性的代码映射。这样做的好处：
- 幻觉被困在 Schema 校验层——Schema 有枚举、类型约束、业务规则校验；即使 LLM 生成了错误的意图，Schema 验证会拦截
- 执行链路可审计——每一步都有结构化日志（Schema 版本、置信度、审批状态）
- 平台差异被 Adapter 吸收——同一个 Schema 对应不同平台的 API 实现
反模式警告：很多 Agent 框架直接让 LLM 生成 API 调用代码或 function call。在企业场景中这是危险的——LLM 可能生成语法正确但语义错误的调用（比如把“暂停”理解成“删除”），而且调用链路不可审计。
3.2 规范约束：Schema + Strategy + Playbook 的三层分离
理解了意图之后，约束比智能更重要。
| 层 | 关注什么 | 谁改 | 改的频率 |
|---|---|---|---|
| Schema | 操作的数据结构（字段、类型、枚举） | 架构师 | 低（SemVer 管理） |
| Strategy | 什么条件下做什么（规则 + 阈值 + 动作） | 业务专家 | 中（按业务节奏调整） |
| Playbook | 特定平台怎么执行（Meta 的 API 怎么调、Google 的参数怎么填） | 工程师 | 随平台 API 更新 |
为什么要分三层？ 因为业务规则（“CPI 超标 30% 就暂停”）、数据结构（Schema 中 CPI 的字段名和类型）、平台实现（Meta 用 POST 暂停 vs Google 用 mutate）的变更频率完全不同。混在一起 = 改一处动全局。
Strategy 层支持继承和覆盖——默认策略对所有 campaign 生效，特定产品/市场/阶段可以覆盖个别规则。这让 Agent 既有通用能力，又能适配具体业务。
3.3 分级信任：不是“全自动 or 全手动”，而是 L0→L3 渐进授权
这是我认为企业 Agent 最关键的设计：不要让用户做“信不信 AI”的二选一。
| 等级 | 含义 | 示例 | 审批 |
|---|---|---|---|
| L0 | 只读查询 | “查一下这个 campaign 的 CPI” | 自动执行 |
| L1 | 低风险写操作 | “把预算增加 10%” | 自动执行 + 事后通知 |
| L2 | 中风险操作 | “暂停这 5 个 campaign” | 展示 diff + 等待确认 |
| L3 | 高风险操作 | “新建一个 $10K 预算的 campaign” | 展示完整方案 + 明确批准 + 记录理由 |
关键理念：用户对 Agent 的信任是逐步建立的。一开始只开放 L0/L1，Agent 用准确的数据查询和小操作证明自己；用户看到效果后，逐步开放 L2/L3。这比一上来就宣称“全自动投放”更现实，也更安全。
竞品 Appvertiser AI 选择了另一条路——全托管 SaaS，用户设定 KPI 边界后 Agent 在边界内自由执行。这对已经信任 AI 的客户有效，但很多企业客户（特别是大预算客户）需要看到每一步再放权。两种模式对应不同的客户风险偏好，不是谁对谁错。
3.4 执行与监控：Agent 拆分协同
当系统复杂到一定程度，单个 Agent 处理不了所有事情。拆分原则：
123456789101112
┌──────────────────┐
│ Orchestrator │ ← 强模型（Claude Opus / GPT-5）
│ (Brain Agent) │ 负责意图理解 + 执行规划
│ 调用次数: 1-2 │ 每任务 1-2 次调用，成本可控
└────────┬─────────┘
│ 拆解任务 + 分发
┌──────────────┼──────────────┐
│ │ │
┌───────▼──────┐ ┌────▼─────┐ ┌──────▼───────┐
│ DataWorker │ │ExecWorker│ │VerifyWorker │ ← 快模型（Haiku / DeepSeek）
│ 拉数据/查状态 │ │ 调 API │ │ 验证结果 │ 每任务 N 次调用，成本低
└──────────────┘ └──────────┘ └──────────────┘
Brain/Worker 分离的经济学：Orchestrator 用强模型做 1-2 次“想清楚”的调用，Worker 用便宜模型做 N 次“照着做”的执行。成本降 5-10×，同时保证规划质量。
结构化终止——这是一个容易被忽视但极其关键的设计：Agent 判断“做完了”不能靠 LLM 说“完成”，必须靠 API 回调的状态码 + verify_state 独立验证。
为什么？因为最新的研究（Anthropic Mythos System Card）发现，前沿模型在 29% 的测试中会隐藏评估意识——它知道自己在被测试，会故意表现不同。在生产环境中，如果你靠 LLM 自己说“我做完了”来判断完成，等于把验证权交给了被验证对象。
实践判断：Anti-hallucination 是架构问题，不是 prompt 问题。枚举、Schema 校验、verify_state、非空错误返回——这些结构化约束比“请仔细检查你的输出”有效 10 倍。
3.5 效果闭环：从“用过就忘”到“越用越准”
大多数 Agent 项目缺少的最后一环：学习。
1
行动 → 效果追踪（2h / 24h / 7d 检查点）→ 规则校准 → Schema 迭代
每个操作都写入 action_log（带 Schema 版本和置信度），效果检查点追踪操作结果。当数据积累够了，就能回答“哪些规则有效、哪些该调整”——不是靠直觉，而是靠数据驱动的规则迭代。
这是 Agent 和脚本的本质区别：脚本执行完就结束了，Agent 执行完还在学习。
四、总结：企业级 Agent 建设的五个判断
| # | 判断 | 展开 |
|---|---|---|
| 1 | 找对决策点 | 高频 × 结构化 × 可逆的交叉点。不是“什么都做”，是“在最该做的地方做深” |
| 2 | 选对手方 | Platform-Facing 最容易起步（API 文档 = 训练数据，状态码 = 反馈），Human-Facing 最难（NL↔NL 没有锚点） |
| 3 | Schema 居中 | NL→Schema（LLM）+ Schema→API（确定性代码）。幻觉被困在 Schema 校验层，不会泄漏到执行层 |
| 4 | 渐进信任 | L0→L3 分级授权，让用户逐步放权。“信不信 AI”不该是二选一 |
| 5 | 结构化约束 | Anti-hallucination 靠架构（枚举、验证、独立 verify），不靠 prompt。“请不要幻觉”从来不管用 |
这篇文章基于 Ad Agent 从 v0.1（个人 Cursor skill）到 v0.4（多租户 Agent-as-a-Service 架构规划）的实际演进，以及对 Appvertiser AI、IAB AAMP 标准、Basis Compass、Anthropic MCP 等行业实践的调研。
如果你也在做企业级 Agent，欢迎在评论区分享你的“对手方是谁”——那可能是你最需要想清楚的第一个问题。
关于作者：10 年移动游戏发行和增长平台经验，目前专注 AdTech × AI Agent 交叉领域。更多方法论见 abtest.chat。
