AI 销售代理真正进入业务流程后，难点就不再是“能不能生成一段销售话术”，而是能否持续使用可信数据、遵守业务边界、调用正确工具，并让团队看清每一次决策。AgentFlo 在 Amazon Bedrock AgentCore 与 AWS 无服务器架构之上，围绕三层防护、数据 grounding 和端到端可观测性构建销售代理。来源摘要提到，这套实践带来了 12% 的净收入提升；同时，团队还在探索实时语音和服务端工具执行。
销售代理的可靠性来自三层控制
一个面向客户的销售代理至少需要控制三类风险：输入是否可信、输出是否合规、动作是否被授权。可以将防护拆成三层：
- 输入与意图层：识别越权请求、提示注入、敏感信息和不属于销售流程的问题。
- 生成与事实层：要求模型只使用经过检索的数据，避免编造价格、库存、合同条款或折扣政策。
- 工具与执行层：对 CRM、订单、报价等服务实行显式 allowlist，并在写操作前检查权限和审批状态。
这三层不能由一条系统提示词替代。提示词可以描述规则，但真正的授权、校验和审计应该落在服务端代码与基础设施中。模型提出“调用更新报价工具”只是一个意图，是否允许执行必须由策略层决定。
下面是一个不依赖 AWS SDK 的最小策略示例。它可以直接运行，也可以把 policy_check 替换成 Lambda、Step Functions 或 AgentCore 工作流中的服务端节点。
运行前无需安装第三方依赖：
from dataclasses import dataclass
from typing import Dict, List
ALLOWED_TOOLS = {"search_catalog", "create_draft_quote"}
SENSITIVE_TERMS = {"password", "信用卡号", "secret"}
@dataclass
class AgentRequest:
user_id: str
intent: str
tool: str | None
arguments: Dict[str, str]
evidence: List[str]
def policy_check(request: AgentRequest) -> tuple[bool, str]:
text = f"{request.intent} {request.arguments}".lower()
if any(term.lower() in text for term in SENSITIVE_TERMS):
return False, "request contains sensitive information"
if request.tool and request.tool not in ALLOWED_TOOLS:
return False, f"tool is not allowlisted: {request.tool}"
if request.tool == "create_draft_quote" and not request.evidence:
return False, "a quote requires grounded evidence"
return True, "allowed"
request = AgentRequest(
user_id="sales-42",
intent="create a draft quote for the enterprise plan",
tool="create_draft_quote",
arguments={"plan": "enterprise", "quantity": "20"},
evidence=["catalog://enterprise-plan/v3"],
)
allowed, reason = policy_check(request)
print({"allowed": allowed, "reason": reason})
生产环境还应加入租户隔离、字段级权限、幂等键、人工审批和超时策略。尤其是创建订单、修改折扣、发送合同等不可逆动作，不应因为模型“看起来很确定”就自动执行。
Grounded data 是销售代理的业务底座
销售代理的回答质量取决于它能访问什么数据，而不仅仅取决于模型能力。AgentFlo 的实践重点包括 grounded data foundation：代理需要从经过治理的产品、客户和销售知识中检索上下文，再生成回答或提出动作。
一个可落地的数据链路可以这样设计：
- 产品目录、价格和库存进入统一数据源，并记录版本与生效时间。
- 销售政策、折扣规则和合同条款按权限切分，检索时带上租户、地区和角色过滤条件。
- 每个回答保存引用的文档 ID、版本和更新时间，方便复核。
- 当检索不到足够证据时，代理应明确表示无法确认，并转人工或创建待办，而不是猜测。
“有引用”不等于“事实正确”。检索结果可能过期，也可能与当前客户上下文不匹配。因此，生成前还需要校验价格有效期、币种、客户等级和库存状态。对于高价值交易，可以让模型只负责整理候选方案，把最终计算交给确定性的后端服务。
可观测性要覆盖一次完整会话
只记录模型最终文本，无法回答销售团队真正关心的问题：代理看到了哪些数据？为什么选择这个工具？工具返回了什么？哪一步增加了延迟？
端到端追踪至少应关联以下信息：
conversation_id、tenant_id、user_id和请求时间。- 模型版本、提示模板版本和检索文档版本。
- guardrail 决策、工具名称、参数摘要和工具返回状态。
- 延迟、token 用量、错误类型、转人工原因和最终业务结果。
日志中不要直接写入完整客户隐私数据、访问令牌或支付信息。可以使用字段脱敏、哈希化客户标识和结构化 JSON 日志。下面的 Lambda 风格示例展示了一个基本的追踪边界；实际部署时，可以把 emit_trace 对接 CloudWatch、OpenTelemetry 或现有的集中式日志系统。
import json
import time
import uuid
def emit_trace(event_name, trace_id, **fields):
record = {
"event": event_name,
"trace_id": trace_id,
"timestamp_ms": int(time.time() * 1000),
**fields,
}
print(json.dumps(record, ensure_ascii=False))
def lambda_handler(event, context):
trace_id = event.get("trace_id", str(uuid.uuid4()))
emit_trace(
"agent.request",
trace_id,
conversation_id=event.get("conversation_id"),
tenant_id=event.get("tenant_id"),
intent=event.get("intent"),
)
# 这里替换为实际的检索、guardrail 和 AgentCore 调用。
evidence = event.get("evidence", [])
if not evidence:
emit_trace("agent.handoff", trace_id, reason="insufficient_evidence")
return {"statusCode": 202, "body": "handoff_required"}
emit_trace(
"agent.tool_planned",
trace_id,
tool="search_catalog",
evidence_count=len(evidence),
)
return {"statusCode": 200, "body": "grounded_response_ready"}
可观测性还要连接业务指标。净收入提升、转化率、平均响应时间、转人工率、错误工具调用率和客户投诉率应放在同一套分析链路中。摘要提到的 12% 净收入提升，只有与对照组、时间窗口、客户分层和成本变化一起观察，才足以支持推广决策。
面向实时语音和服务端工具执行
实时语音会把文本代理中的问题放大：延迟直接影响对话体验，打断和重试会增加状态管理复杂度，语音转写错误还可能触发错误的工具调用。可以先将语音层与业务决策层解耦：语音负责流式输入输出，AgentCore 负责会话编排，服务端策略层负责数据访问与动作授权。
服务端工具执行也应遵循几个边界：
- 模型只能选择工具和提供候选参数，不能携带凭证直接访问内部系统。
- 工具服务在每次调用时重新验证身份、租户和资源权限。
- 写操作使用幂等键，并在执行结果中返回明确的状态。
- 高风险动作采用人工确认或双重审批。
- 每次工具调用都写入可关联到会话的审计事件。
采用清单
将 AI 销售代理投入生产时，可以逐项检查：
- 是否有独立于模型提示词之外的授权策略？
- 每个关键回答是否能追溯到数据版本和引用？
- 所有写工具是否默认关闭，并通过 allowlist 开启？
- 是否记录完整链路，同时完成隐私脱敏？
- 是否用业务结果和成本，而不是只用回答流畅度评估代理？
- 语音、工具执行和人工交接是否有明确的超时与降级路径？
AgentCore 和无服务器架构可以提供代理运行所需的托管能力，但可信度仍来自工程边界：数据必须可验证，动作必须可授权，故障必须可追踪。AgentFlo 的下一步方向说明，销售代理的竞争点正在从“会聊天”转向“能在真实业务约束下稳定完成工作”。