GlobalCart运营Agent解剖：路由逻辑、成本控制与失败边界

Support Triage 不是简单的"调用工具"——它是核心业务逻辑

LLM agent 演示通常用 chain-of-thought prompting 来编排工具调用：总结一下，也许调一个退款 API。这不是生产级 support。GlobalCart 运营 agent 处理的是真实的大规模客户工单。每张工单都有结构——订单、争议、边缘支付场景。路由是一个分支决策图，结合了确定性代码、LLM 补全和合规要求的检查。

生产级 agent 必须低成本地关闭工单、命中 SLA、带审计追踪进行升级，且不能让自己的 API 账单飙到 200 美元。

路由是结构化的，不只是 LLM"胶水代码"

以下是部署在 globalcart-operations-agent 中的主要路由函数。确定性逻辑处理常见工单，LLM 处理模糊分支。

def route_ticket(ticket):
    # Hard-coded rules for frequent cases
    if ticket['type'] == 'refund' and ticket['order_status'] == 'delivered':
        return call_tool('initiate_refund', ticket)
    if ticket['type'] == 'cancellation' and not ticket['is_shipped']:
        return call_tool('cancel_order', ticket)

    # Edge cases: nonstandard issues forwarded to LLM
    llm_query = build_triage_prompt(ticket)
    llm_response = call_llm('triage', llm_query)

    if 'escalate' in llm_response['intent']:
        return escalate_to_human(ticket)
    if 'tool:' in llm_response['actions'][0]:
        tool, params = parse_tool_call(llm_response['actions'][0])
        return call_tool(tool, params)

    # Dead letter: nothing worked
    log_unresolved(ticket)
    return escalate_to_human(ticket)

分叉发生在确定性规则或 LLM 支持的工具调用没有覆盖的决策点。这些情况会强制升级（成本高昂），或者——如果没有检查——会导致静默循环和死锁。

升级成本快速膨胀——真实日志、真实美元

LLM 运维单独看很便宜。实际上，让太多工单偏离快乐路径（确定性解决）会导致成本飙升，尤其是当模糊性在工具和人工之间反复弹跳时。

样本日志摘录（美元值来自 OpenAI/Azure 账单，2024 年初）：

[1] Tool: order_lookup | $0.007
[2] LLM: triage-prompt | 750 tokens | $0.018
[3] Tool: refund_init | $0.005
[4] LLM: clarify-user-intent | 850 tokens | $0.019
[5] Escalation: human agent | $2.10 (avg, blended global)

相比之下，一次干净的确定性案例：

[1] Tool: cancel_order | $0.006

以及一次无保护的循环（日志摘录，已简化）：

[1-10] LLM: triage-prompt (loop: unclear intent) | 10x 750 tokens | $0.18
[11] Escalation: human agent | $2.10

各模式下的单张工单成本，12 周生产窗口（美元）：

来源：内部运维报告及 OpenAI/Azure 账单日志，2024 年。

Guardrails 阻止了大多数故障——但不是全部

没有 guardrails 的 agent 无法在生产环境存活，guardrails 作用于工具选择、输出验证和循环预防。以下是 GlobalCart guardrail 模块的示例：

def validate_llm_response(response):
    # Only allow defined tools
    allowed_tools = {'initiate_refund', 'cancel_order', 'order_lookup'}
    if response.get('tool') not in allowed_tools:
        log_violation("tool_not_allowed", response)
        return False

    # Prevent excessive retries
    if too_many_retries(response['ticket_id']):
        escalate_to_human(response['ticket_id'])
        return False
    return True

这阻止了越界工具调用，并在反复失败时触发升级。仍有漏洞：模糊的 LLM 输出落在可识别动作和升级之间，尤其是在意图到动作的映射不清晰时。

漏洞示例（成本：$5.17，27 次不足 1 美分的 LLM 调用，从未触发重试 guard）：

TOOL_LOOP_DETECTED | ticket: 672182 | attempts: 27 | total_cost: $5.17 | error: LLM 在 'order_lookup' 和 'clarify_status' 之间摇摆，从未升级。

Guardrails 减少了漏洞，但模糊的意图仍是成本的一个来源。

故障模式：静默循环、死锁和无上限支出

生产环境中的两大主要故障：静默循环（LLM 振荡，数十步工具/分流）和死锁（agent 什么都不做，工单烂到 SLA 扫除）。

2024 年 Q1 最昂贵的 bug：一个 VAT 退款类别的错误路由。LLM 在 "order_lookup" 和 "clarify_vat_status" 之间交替，但由于软重试计数器 bug，升级阈值从未触发：

# Retry counter mistakenly reset in recursion
def route_ticket(ticket):
    retries = 0  # Should use ticket['retries'], but resets each call
    while retries < 10:
        ...
        retries += 1
        response = call_llm(...)
        # critical bug: 'retries' lost across recursive calls

成本：3 周内跑了 9700 美元的无控制计算才打上补丁。

死锁也发生在 LLM 输出模糊时：

LLM: suggest_action = ['investigate_purchase']
Guard: not a recognized tool, not 'escalate'
Result: ticket stays open, SREs clean up days later.

静默故障驱动真实成本：AWS、Azure 和账单日志每个季度都会暴露它们。

什么带来了 ROI：确定性优于 LLM 调优

在高容量工单上加倍投入硬编码规则，使 LLM 和升级费用都实现了双位数的下降。添加严格的工具 guard 和重试上限又节省了 12% 的支持成本。

尝试 LLM fine-tuning—— nudge 对长尾或公司特定流程的理解——没有太大改变。一旦 agent 缺乏解决工单所需的数据或端点，边际收益就被吞掉了。瓶颈在前端。

一个可靠省钱的手柄：每当 agent 不确定时，默认升级。这在歧义或循环工单累积成本之前将它们清除。

必要投入：

80% 案例的全面、明确的规则。

路由中的硬重试/升级阈值。

自动化漏洞检测——不在 LLM 评估中，而是在实时运维成本分析中。为昂贵/慢速工单接入触发器，而不是只看 token 级别的质量评分。

进一步的 LLM 技巧产生递减收益。在你修复数据质量、充实 API 并为静默 agent 故障埋点之前，你的 support agent 会在边缘案例上持续失血——没有任何 prompt 能解决。

参考实现：globalcart-operations-agent，agent-roi-console。