客服 Agent 真正困难的部分，不是生成一句流畅回答，而是判断何时检索知识库、何时继续追问、何时转给人工，以及如何把整个过程沉淀为可追溯的工单。AgentDesk v1.6.3 将运行时升级为 Agent First 架构，试图用统一的自主循环和上下文评估，把在线咨询、知识库问答、人工接管与工单处理放进同一条业务链路。
Agent First 改变的是运行方式
传统客服机器人通常按固定流程工作：识别意图、命中知识、生成回复。它适合边界清晰的高频问题，但一旦用户补充条件、切换诉求或要求执行后续动作，流程很容易断裂。
Agent First 架构更接近一个持续运行的决策循环：
- 接收用户消息和会话上下文。
- 评估当前问题、已知信息与风险。
- 决定直接回答、查询知识库、继续澄清、创建工单或请求人工接管。
- 执行动作并记录结果。
- 将新结果放回上下文，进入下一轮评估。
这次更新摘要明确提到统一自主循环与上下文评估。其价值不只是让模型“更自主”，而是让不同客服动作拥有一致的运行入口。团队因此可以围绕同一套会话状态设计权限、审计、超时和人工介入规则。
一条客服链路需要哪些状态
把 Agent 接入真实业务时，建议不要只保存聊天记录。至少应区分以下几类数据：
- 会话状态：当前由 AI 处理、等待用户、等待人工，还是已经关闭。
- 业务上下文：用户身份、订单号、产品版本、历史工单和已确认事实。
- 决策记录：Agent 为什么查询某篇知识、创建哪类工单或触发转人工。
- 动作结果：知识库命中内容、外部系统返回值、工单编号与人工处理结果。
- 风险信号：低置信度、用户投诉、退款请求、敏感操作或连续失败次数。
其中“转人工”不应只是发送一句“请稍候”。交接数据需要包含问题摘要、已执行动作、待确认事项和相关业务标识。否则人工客服仍要从头阅读对话，AI 只缩短了回复时间，却没有缩短处理时间。
可以这样实践：给 Agent 增加可审计的动作网关
下面是一个可直接运行的最小 FastAPI 示例，用来演示 Agent 如何通过统一网关创建工单或请求人工接管。它不是 AgentDesk 官方接口定义，而是根据统一运行时思路给出的集成样例；接入时需要把内存存储替换为实际工单系统，并按 AgentDesk 的真实接口调整字段。
安装并启动：
python -m venv .venv
. .venv/bin/activate
pip install fastapi uvicorn
uvicorn app:app --reload --port 8080
创建 app.py：
from datetime import datetime, timezone
from typing import Literal
from uuid import uuid4
from fastapi import FastAPI
from pydantic import BaseModel, Field
app = FastAPI(title="Customer Service Action Gateway")
EVENTS: list[dict] = []
class AgentAction(BaseModel):
conversation_id: str
action: Literal["create_ticket", "handoff"]
reason: str = Field(min_length=3)
summary: str = Field(min_length=3)
customer_id: str | None = None
confidence: float = Field(ge=0, le=1)
@app.post("/agent/actions")
def execute_action(request: AgentAction):
event = {
"event_id": str(uuid4()),
"created_at": datetime.now(timezone.utc).isoformat(),
**request.model_dump(),
"status": "queued",
}
EVENTS.append(event)
return event
@app.get("/conversations/{conversation_id}/events")
def list_events(conversation_id: str):
return [
event for event in EVENTS
if event["conversation_id"] == conversation_id
]
触发一次人工接管：
curl -sS http://localhost:8080/agent/actions \
-H 'Content-Type: application/json' \
-d '{
"conversation_id": "conv-2025-001",
"action": "handoff",
"reason": "用户要求退款，必须由有权限的人工客服确认",
"summary": "用户反馈订单重复扣款，已核对订单号，尚未执行退款",
"customer_id": "customer-42",
"confidence": 0.62
}'
查询该会话的动作记录：
curl -sS http://localhost:8080/conversations/conv-2025-001/events
这个示例刻意把 reason、summary 和 confidence 设为显式字段。生产环境还应补充调用方认证、幂等键、租户隔离、敏感信息脱敏、持久化存储和失败重试。尤其是创建退款、修改账户或发送补偿等高风险动作，不能只凭模型生成的参数直接执行。
上线时把自主权拆成等级
Agent First 不等于把所有决定交给模型。更稳妥的做法是按风险配置动作权限：
| 等级 | Agent 能力 | 适用动作 |
|---|---|---|
| L1 | 生成建议，人工发送 | 投诉、退款、合规咨询 |
| L2 | 自动回复，可随时接管 | 知识库问答、状态查询 |
| L3 | 自动调用低风险工具 | 创建普通工单、补充标签 |
| L4 | 条件满足后执行 | 需要额度、身份或规则校验的操作 |
上线前可以用一份简短清单约束范围：确认每个动作都有审计记录；定义低置信度与连续失败的转人工阈值；验证人工接管后 Agent 不再重复发言；限制知识库内容和工具权限；统计一次解决率、转人工率、误操作率与平均处理时长。
AgentDesk v1.6.3 所体现的方向，是把 AI 从客服界面的一个回复组件，推进为业务链路中的运行单元。真正决定效果的仍是状态模型、工具权限、交接质量与审计机制。先从低风险问答和工单分流开始，再逐步开放动作权限，通常比一次性追求全自动更容易控制成本和风险。