上一篇讲的是理念：解决方案对象、拜访质检、履约 SOP 编译。这一篇讲落地：FDE 到客户现场，怎么用基础设施在一天内把这些理念变成可运行的 Agent。

老周（售前）和小林（FDE）一起到了汽配客户现场。客户有 200 家门店，销售团队 30 人，每天处理 50+ 客户咨询、20+ 报价单、10+ 合同审批。

问题是：销售流程全靠人肉，信息散落在微信、Excel、邮件里，老周那份 80 页 PPT 签完单就死了。

09:00 — 业务调研（用 SOP 采集器）

小林不是拿着笔记本记，而是打开钉钉小程序「SOP 采集器」，跟着销售总监走了一遍完整流程：

客户咨询
    ↓
需求确认（30 分钟）
    ↓
报价（2 小时，等财务确认成本）
    ↓
方案讲解（1 小时）
    ↓
合同审批（3 天，等法务 + 总经理）
    ↓
签约（1 天）
    ↓
交付（5 天）
    ↓
售后（持续）

小林问：「哪个环节最耗时？」

销售总监：「报价和合同审批。报价要等财务算成本，合同要等法务审条款，加起来 5 天。但真正干活的时间不到 4 小时，剩下全是等待。」

小林在采集器里标注：

{
  "step": "报价",
  "duration_hours": 48,
  "active_hours": 2,
  "wait_hours": 46,
  "bottleneck": "财务确认成本",
  "ai_opportunity": "历史报价 + 成本模型 → 自动报价",
  "roi": "30 销售 × 20 报价/月 × 46 小时/报价 = 27,600 小时/月"
}
# generated by hugo AI

ROI 计算器自动算出：如果报价环节从 48 小时降到 4 小时，每月节省 27,600 小时等待时间，折合 115 个工作日。

这就是业务抽象能力里说的：不是听到「报价慢」就做一个报价工具，而是算出「等待时间 × 人数 × 频次」的真实成本。

11:00 — 工作流抽象（用工作流画布）

小林打开 Web 画布，把销售流程拆成 Agent 矩阵：

销售流程 Agent 矩阵
┌─────────────────────────────────────────────────────────────┐
│  CRM Agent        客户画像 + 历史记录 + 跟进提醒             │
│  报价 Agent       历史报价 + 成本模型 + 自动报价 + 审批       │
│  合同 Agent       条款模板 + 法务审核 + 电子签章             │
│  方案 Agent       解决方案对象 + 竞品对比 + PPT 生成         │
│  交付 Agent       履约 SOP 编译 + 进度追踪 + 异常预警        │
│  售后 Agent       客户反馈 + 续约预警 + 增购推荐             │
└─────────────────────────────────────────────────────────────┘

不是一个超级 Agent。

而是六个专业 Agent 协作。

小林在画布上标注每个 Agent 的输入输出：

CRM Agent
  输入：客户咨询（钉钉群消息）
  输出：客户画像卡片（AI 表格）
  
报价 Agent
  输入：客户需求（CRM Agent 输出）
  输出：报价单（PDF）+ 审批请求（钉钉审批流）
  
合同 Agent
  输入：报价单 + 客户资质
  输出：合同草案（钉钉文档）+ 法务审核请求

这就是工作流思维：把岗位工作拆成多个专业 Agent，每个 Agent 只做一件事，协作完成端到端流程。

14:00 — Agent 设计（用 Agent 脚手架）

下午，小林打开终端，用脚手架快速创建第一个 Agent：

dws agent create quote-agent \
  --template pricing-automation \
  --scope channel:销售报价群 \
  --bundle sales-pricing

脚手架自动生成项目结构：

quote-agent/
├── agent.yaml          # Agent 配置
├── tools/
│   ├── pricing_model.py    # 报价模型
│   └── approval_flow.py    # 审批流
├── mcp/
│   └── dingtalk_table.py   # AI 表格 MCP Server
└── README.md

小林编辑 agent.yaml：

name: 报价 Agent
agent_id: agent://sales-pricing
memory_scope: workspace
triggers:
  - event: message_received
    pattern: "报价|询价|价格"
tools:
  - name: query_historical_quotes
    mcp_server: dingtalk-table
    params:
      table: 历史报价
      fields: [客户, 产品, 单价, 日期]
  - name: calculate_cost
    mcp_server: erp-cost
    params:
      product_id: required
      quantity: required
  - name: create_approval
    mcp_server: dingtalk-approval
    params:
      template: 报价审批
outputs:
  - type: dingtalk_message
    template: 报价单卡片
  - type: dingtalk_approval
    condition: amount > 100000
# generated by hugo AI

然后接入 MCP Server：

dws mcp connect dingtalk-table --token xxx
dws mcp connect erp-cost --token yyy
dws mcp connect dingtalk-approval --token zzz

30 秒接好三个系统。

小林用 AI Coding 写了一个简单的报价模型：

from dataclasses import dataclass
from typing import Optional

@dataclass
class QuoteAgent:
    """报价 Agent：历史报价 + 成本模型 → 自动报价"""
    
    agent_id: str = "agent://sales-pricing"
    memory_scope: str = "workspace"
    
    def query_historical_quotes(self, customer: str, product: str) -> list:
        """查询历史报价"""
        return self.mcp_call("dingtalk-table", "query", {
            "table": "历史报价",
            "filter": f"客户='{customer}' AND 产品='{product}'",
            "order_by": "日期 DESC",
            "limit": 5,
        })
    
    def calculate_cost(self, product_id: str, quantity: int) -> float:
        """调用 ERP 计算成本"""
        return self.mcp_call("erp-cost", "calculate", {
            "product_id": product_id,
            "quantity": quantity,
        })
    
    def generate_quote(self, customer: str, product: str, quantity: int) -> dict:
        """生成报价单"""
        history = self.query_historical_quotes(customer, product)
        cost = self.calculate_cost(product, quantity)
        
        # 简单模型：历史均价 × 1.2（20% 毛利）
        if history:
            avg_price = sum(h["单价"] for h in history) / len(history)
            unit_price = max(avg_price, cost * 1.2)
        else:
            unit_price = cost * 1.3  # 新客户 30% 毛利
        
        total = unit_price * quantity
        return {
            "customer": customer,
            "product": product,
            "quantity": quantity,
            "unit_price": unit_price,
            "total": total,
            "approval_required": total > 100000,
        }
    
    def create_approval(self, quote: dict) -> str:
        """发起审批流"""
        if quote["approval_required"]:
            return self.mcp_call("dingtalk-approval", "create", {
                "template": "报价审批",
                "data": quote,
                "approvers": ["财务经理", "销售总监"],
            })
        return "auto_approved"
# generated by hugo AI

16:00 — 部署上线（用 Agent Proxy + Access Bundle）

小林部署 Agent 到销售报价群：

dws agent deploy quote-agent --scope channel:销售报价群

背后发生了什么？

1. Agent Registry 注册身份

{
  "agent_id": "agent://sales-pricing",
  "display_name": "报价 Agent",
  "department": "销售部",
  "bundle": "sales-pricing",
  "memory_scope": "workspace"
}

Agent 有自己的身份，不是借用销售总监的 Token。

2. Access Bundle 绑定权限

name: sales-pricing
connections:
  - name: dingtalk-table
    host: table.dingtalk.com
    credential_ref: table_token_sales
    mode: read
    path_prefix: /api/v2/tables/历史报价
  
  - name: erp-cost
    host: erp.customer.com
    credential_ref: erp_api_key
    mode: read
    path_prefix: /api/cost
  
  - name: dingtalk-approval
    host: approval.dingtalk.com
    credential_ref: approval_token
    mode: write
    path_prefix: /api/v2/approvals

allowed_domains:
  - dingtalk.com
  - customer.com

Agent 只能访问「历史报价表」，不能访问「客户黑名单表」；只能读 ERP 成本，不能改价格。

3. Agent Proxy 边界注入

Agent 在沙箱里运行，沙箱不持有任何凭证。

Agent 调用 MCP Server 时：

Agent: requests.get("https://erp.customer.com/api/cost?product_id=123")
    ↓ (沙箱内 DNS 劫持)
Agent Proxy: 检查 Connection Rules
    ↓ (命中 erp-cost, mode=read)
Agent Proxy: 注入 erp_api_key → 转发请求
    ↓
ERP: 返回成本数据（Agent 看不到 API Key）

即使 Agent 被 prompt injection 攻击，也泄露不了 API Key——因为凭证根本不在沙箱里。

这就是 Agent IAM 架构的三层设计：Session Sandbox + Agent Proxy + Access Bundle。

4. 双轨审计

每次 Agent 操作，日志同时记录人和 Agent：

{
  "timestamp": "2026-06-29T14:30:00+08:00",
  "human_requester": "张三 (销售)",
  "agent_executor": "agent://sales-pricing",
  "session_id": "ses_thread_xyz",
  "action": "generate_quote",
  "data_source": "dingtalk-table://历史报价",
  "access_bundle": "sales-pricing",
  "result": {
    "customer": "汽配连锁 A",
    "total": 150000,
    "approval_required": true
  },
  "proxy_log": [
    {"host": "table.dingtalk.com", "status": "forwarded", "credential": "table_token_sales"},
    {"host": "erp.customer.com", "status": "forwarded", "credential": "erp_api_key"},
    {"host": "approval.dingtalk.com", "status": "forwarded", "credential": "approval_token"}
  ]
}

出了事能追溯：是张三发起的，报价 Agent 执行的，用了销售报价 Bundle 的权限。

18:00 — 产品沉淀（用模式库）

晚上，小林回到酒店，写了一份模式识别报告：

本周客户调研（5 家销售型公司）

共同模式：
  - 报价环节耗时最长（5/5）
  - 历史报价散落在 Excel（5/5）
  - 审批流程断裂：销售不知道审批到哪了（4/5）
  - 缺少「报价 → 合同 → 交付」的链路追踪（5/5）

已验证 Agent：
  - 报价 Agent（汽配客户 A，上线 1 天，处理 12 个报价，平均 15 分钟/个）
  - ROI：从 48 小时 → 4 小时，节省 44 小时/报价

建议：
  - 进入「钉钉销售 Agent」产品规划
  - 优先做「报价 Agent + 合同 Agent」
  - 复用 [解决方案对象](https://hugozhu.site/post/2026/251-ai-native-sales-presales-solution-object/) 模式
  - 参考 [拜访质检](https://hugozhu.site/post/2026/252-ai-native-sales-pitch-qa-coaching/) 的方案校验逻辑

如果十家公司都在做「报价自动化」，那就应该进入「钉钉销售 Agent」产品规划，而不是继续实施。

基础设施全景

以销售流程为例，FDE 用到的基础设施：

时间	阶段	基础设施	作用
09:00	业务调研	SOP 采集器 + ROI 计算器	量化等待时间成本
11:00	工作流抽象	Web 画布	拆出 6 个专业 Agent
14:00	Agent 设计	Agent 脚手架 + MCP Server	30 秒接好钉钉表格、ERP、审批
16:00	部署上线	Agent Registry + Proxy + Bundle	安全隔离 + 权限控制 + 双轨审计
18:00	产品沉淀	模式库	识别「10 家客户都做了报价 Agent」

一句话总结：基础设施让 FDE 从「做项目」变成「做产品」——一天验证一个业务想法，一周沉淀一个标准 Agent。

你的企业销售流程里，哪个环节最耗时？是报价、合同、还是交付？有没有想过用 Agent 矩阵来拆解？欢迎留言讨论。

FDE 基础设施实战：一天做出销售 Agent 矩阵

Infrastructure in Action — Building a Sales Agent Matrix in One Day