Agent扩展设计--action设计
action是智能体的“可扩展”架构的设计
Agent 永远只看 action，不看 expected_action，也不看 intent。
✅ 给 ReactAgent 新增 action，不动 Coordinator
✅ 替换 RAGAgent 实现，不改 dataset
✅ 一个 intent → 多 action（上下文驱动）
✅ 做 A/B Test：同 intent 不同 action 策略
✅ 方便做评测设计
action vs expected_action
expected_action 不直接参与线上逻辑判断，它是：
- 离线评测的“标准答案”
- 线上决策结果（action）的对照物
- 真正参与运行的是 action，不是 expected_action。
实现中你要做的是： - Coordinator 产出 action
- Agent 根据 action 执行
Langfuse 用 expected_action 对比 action
意图 VS action VS objection
-Intent = 用户在关心什么
-Action = 系统现在要做什么
- Intent Objection Action
阶段一：非 Objection 阶段（探索 / 信息获取）
Intent
↓
Action（基于上下文的最优下一步）
阶段二：Objection 阶段（犹豫 / 抵抗）
Intent
↓
Objection
↓
Action（应对策略）
-Action VS 微服务架构DDD 命令
Action 在传统微服务 + DDD 语境下 = Comman
Action 可以触发事件 Event，用于异步通知和追踪
意图 Intent 是外部需求，Action 是内部命令
这样设计，你的 AI 销售系统就天然可落地微服务和事件驱动架构
一个意图多action的例子
这是一个非常好的问题，因为你已经从“分类式 Agent”走到了“决策式 Agent”。
下面我给你一个完全贴合你跨境销售机器人场景的、可直接落到代码的例子，清晰展示：
同一个 intent，在不同上下文下，Coordinator 会选择不同的 action
场景：PRICE_QUERY（价格相关意图）
用户原始意图（不变）
Intent = PRICE_QUERY
用户表达的核心语义始终是：关心价格
上下文变量（决定 action 的关键）
Coordinator 在做决策时，会同时看到这些上下文：
- 是否已知 SKU
- 是否新客 / 老客
- 是否有库存
- 是否高客单产品
- 是否进入购买后期
一、不同上下文 → 不同 action（业务视角）
情况 1：只问价格（早期）
“Find X8 多少钱？”
上下文
SKU 已知
库存充足
新客
决策结果
{
"intent": "PRICE_QUERY",
"action": "query_price",
"agent": "ReactAgent"
}
📌 行为：直接给价格
情况 2：价格 + 购买信号（中后期）
“Find X8 多少钱？买 3 台有优惠吗？”
上下文
SKU 已知
库存充足
存在批量购买信号
决策结果
{
"intent": "PRICE_QUERY",
"action": "query_price_with_bulk_discount",
"agent": "ReactAgent"
}
📌 行为：
- 报价
- 同时给批量折扣（客单价提升）
情况 3：价格被反复询问（犹豫期）
“这价格有点贵吧？”
上下文
已连续第 3 次询价
用户未下单
决策结果
{
"intent": "PRICE_QUERY",
"action": "recommend_upsell",
"agent": "RAGAgent"
}
📌 行为：
- 不再重复报价格
- 转而解释价值、对比、优势（用 RAG）
情况 4：价格相关，但库存异常
“Find X8 多少钱？”
上下文
SKU 已知
库存为 0
决策结果
{
"intent": "PRICE_QUERY",
"action": "handoff_to_human",
"agent": "Handoff"
}
📌 行为：
- 不报价格
- 转人工处理缺货沟通（防止错误承诺）
二、同一个 intent → 多 action 的本质
Intent 解决的是：
“用户在关心什么？”
Action 解决的是：
“现在最有商业价值、风险最低的下一步是什么？”
三、Coordinator 的决策代码示例（可运行）
def decide_price_action(context) -> Decision:
if context.inventory == 0:
return Decision(
intent="PRICE_QUERY",
action="handoff_to_human",
agent="Handoff"
)
if context.bulk_signal:
return Decision(
intent="PRICE_QUERY",
action="query_price_with_bulk_discount",
agent="ReactAgent"
)
if context.repeat_price_query_count >= 3:
return Decision(
intent="PRICE_QUERY",
action="recommend_upsell",
agent="RAGAgent"
)
return Decision(
intent="PRICE_QUERY",
action="query_price",
agent="ReactAgent"
)
四、这对你做评测意味着什么（非常重要）
你现在可以：
- 对 intent 评测（语义理解）
- 对 action 评测（业务决策）
- 对 action 分布评测（策略是否合理）
例如：
| intent | expected_action | 是否正确 |
|---|---|---|
| PRICE_QUERY | query_price | ❌（错失 upsell） |
| PRICE_QUERY | recommend_upsell | ✅ |
五、这一步为什么是“销售智能体的分水岭”
绝大多数“AI 客服”停在：
intent → response
而你现在的架构已经是：
intent → 策略决策 → action → agent → response
这才是真正能提高转化率和客单价的销售 Agent。
一句话总结
Intent 不变，Action 随上下文变化。
Intent 是理解，Action 是策略。
如果你愿意，下一步我可以直接帮你：
- 把你整个 销售漏斗（询价 → 犹豫 → 决策）拆成 action 状态机
- 或者帮你设计 Coordinator 的上下文特征表（哪些变量值得进决策）
你现在问的，已经是「怎么把 Agent 变成生意系统」的问题了。
浙公网安备 33010602011771号