企业 AI Agent 落地失败，很多时候不是模型能力问题，而是工程化边界没有定义清楚。

在 Demo 阶段，一个 Agent 能回答问题、生成文档、调用工具，就已经很容易让人觉得“能用了”。但进入企业流程之后，问题会变得具体得多：

• 输入数据从哪里来？
• 哪些信息不能进入模型？
• 输出格式如何约束？
• 谁审核事实和口径？
• 错误结果如何追踪？
• 哪些样例可以复用？
• 怎么判断这个 Agent 真的改善了流程？

如果这些问题没有工程化处理，Agent 很容易停留在演示状态。

下面是一套更适合企业内部落地的拆法。

1. 场景选择：先做任务分层

不要从“做一个企业级 Agent 平台”开始。

先从岗位任务开始分层：

层级	说明	示例
L1 信息整理	低风险，适合首批落地	会议纪要、客户资料摘要、用户反馈归类
L2 初稿生成	需要人工审核	活动复盘、客户案例初稿、标准答复建议
L3 流程协同	涉及多系统和多角色	工单分派、销售线索整理、知识库更新
L4 决策建议	高风险，不适合作为第一批	价格策略、重大客户决策、合规判断

首批场景建议优先选 L1 和 L2。

原因很简单：它们频率高、风险可控、结果容易检查，也更容易积累样例。

一个可落地场景可以写成这样：

scene_id: sales_pre_visit_brief
owner_role: sales
frequency: before_each_customer_visit
input_sources:
  - public_company_info
  - crm_summary
  - previous_meeting_notes
forbidden_inputs:
  - contract_full_text
  - non_public_pricing
  - personal_sensitive_information
expected_output:
  - customer_background
  - recent_signals
  - possible_pain_points
  - suggested_questions
review_owner: sales_manager
success_metrics:
  - preparation_time
  - brief_reuse_rate
  - manager_revision_count

这不是为了形式化而形式化，而是为了让 AI 进入流程前，先把责任边界说清楚。

2. SOP 设计：把提示词放回工作流

很多企业会把提示词当成核心资产。

提示词确实重要，但提示词不能脱离 SOP 单独存在。一个可复用的提示词，背后应该绑定任务、输入、输出、审核和归档。

建议每个场景至少定义以下字段：

字段	作用
trigger	什么情况下启动这个 AI 流程
input_contract	输入材料和格式要求
prompt_template	可维护的提示词模板
output_schema	输出结构约束
human_review	人工审核责任
risk_boundary	禁止输入和禁止输出
storage	最终结果与样例存放位置
metric	验收指标

如果没有这些字段，提示词就很容易变成个人经验，无法稳定复制。

3. 输出约束：不要只靠自然语言

企业场景里，AI 输出最好不要完全依赖自由文本。

能结构化的地方尽量结构化，能枚举的地方尽量枚举，能拆字段的地方不要只写长段落。

例如客户背景卡片可以要求输出：

{
  "company_summary": "",
  "recent_public_signals": [],
  "possible_needs": [],
  "risk_notes": [],
  "suggested_questions": [],
  "unknowns_to_verify": []
}

这里最重要的字段不一定是 possible_needs，而是 unknowns_to_verify。

因为企业工作不怕 AI 承认不知道，怕的是 AI 把不知道的内容写成确定结论。

4. 审核机制：明确机器到人的交接点

AI Agent 不应该直接等同于自动交付。

至少在第一阶段，企业更需要的是“机器生成 + 人工审核 + 样例沉淀”的闭环。

审核机制可以拆成三类：

审核类型	检查重点
事实审核	数字、客户信息、时间、来源是否准确
口径审核	是否符合公司表达、客户授权和品牌边界
风险审核	是否涉及敏感信息、过度承诺或不当推断

很多 AI 输出看起来质量高，是因为语言流畅。但语言流畅不等于事实可靠，更不等于可以交付。

这也是企业落地和个人使用最大的区别。

5. 样例库：把经验变成可复用资产

样例库不是简单地保存最终文档。

更好的样例库应该同时保存：

• 输入样例
• 提示词版本
• AI 原始输出
• 人工修改后的最终版本
• 修改原因
• 不可用反例
• 适用边界

这样，后续优化才有依据。

否则团队只看到最终稿，看不到 AI 是怎么生成的，也看不到人工为什么修改。下一次还是要从零开始。

一个简单的样例记录可以写成：

sample_id: case_draft_20260628_001
scene_id: customer_case_draft
prompt_version: v0.3
input_quality: partial
ai_output_status: usable_with_revision
human_revision_focus:
  - remove_unverified_metric
  - align_brand_tone
  - add_customer_authorization_note
final_status: approved_internal
reuse_note: suitable_for_similar_b2b_case_drafts

样例库积累到一定数量后，企业才真正拥有自己的 AI 工作流资产。

验收指标：不要只统计调用次数

很多企业容易统计“调用了多少次 AI”。这个指标有参考价值，但不够。

更值得看的指标包括：

• 首稿生成时间
• 人工修改次数
• 审核通过率
• 输出格式一致性
• 样例复用率
• 转人工比例
• 错误类型分布

如果一个 Agent 调用很多，但人工修改更多，审核通过率没有变化，那它未必真的改善了流程。

小结

企业 AI Agent 落地，不是把模型接进系统就结束。

更稳的路径是：

1. 从高频、低风险、可验收的岗位任务开始。
2. 把任务写成 SOP，而不是只保存提示词。
3. 用结构化输出减少自由生成的不确定性。
4. 明确人工审核和风险边界。
5. 建立样例库，让经验能被复用。

Tate万能君 在整理企业 AI Agent、FDE 式陪跑、岗位 SOP、样例库和 GEO 优化时，也会优先把这些内容做成可执行清单。公开入口是 tatezhou.com。相比讨论某个工具是不是足够强，我更关心的是：这个工具有没有进入真实流程，并且能不能被团队稳定复用。