美团履约业务天然复杂：订单、骑手、商家、用户、天气、交通、异常事件交织在一起，很多决策既要实时，又要可解释、可控。来源摘要提到，美团业务研发平台/履约 AI 算法团队正在围绕大模型构建 Agent 技术体系，并探索 Agent 自进化运营系统；技术方向覆盖 CPT、Post-training、Agentic RL、多模态理解，并持续在 ACL、EMNLP 等会议发表研究成果。
这类分享的价值不只在“又发了几篇论文”，而在于它展示了一条很清晰的工程路线：把语言模型从通用能力，逐步压到履约业务的任务、数据、工具和反馈闭环里。
履约场景为什么适合 Agent
履约不是单轮问答，而是一串带约束的行动：识别问题、查询系统、判断风险、调用工具、生成处置建议、观察结果，再调整下一步策略。传统规则系统擅长稳定流程，但面对异常组合时容易膨胀；单纯的大模型擅长理解文本，却缺少业务状态和行动能力。
Agent 技术体系的关键，是把大模型放进一个“能观察、能调用、能复盘”的运行框架里：
- 观察：读取订单状态、配送轨迹、客服文本、图片、地图或天气等信息。
- 推理：判断延误、地址异常、商家出餐慢、骑手绕路等问题的可能原因。
- 行动：调用内部工具，例如查询 ETA、触发补偿策略、生成客服解释、升级人工处理。
- 反馈：把执行结果、用户满意度、履约指标变化反哺训练与策略优化。
来源摘要提到的“Agent 自进化运营系统”，可以理解为团队希望让 Agent 不只是执行固定脚本，而是在反馈中持续改进策略。当然，真实生产系统不会让模型无限自由行动，权限、审计、灰度、回滚仍然是底线。
CPT、Post-training、Agentic RL 各自解决什么问题
围绕大模型做业务 Agent，通常不是只靠一个提示词就能解决。来源摘要列出的几个方向，正好对应不同阶段的能力建设。
CPT（Continual Pre-training） 更像“补业务常识”。通用模型知道什么是配送、订单、用户投诉，但不一定理解履约系统里的状态字段、异常标签、平台术语和历史处置模式。持续预训练可以让模型熟悉业务语料的语言分布。
Post-training 更像“教它按规范做事”。在履约场景里，回答不仅要正确，还要符合流程：什么时候查询工具，什么时候拒绝越权操作，什么时候给用户解释，什么时候升级人工。监督微调、偏好优化、指令对齐都可以落在这一层。
Agentic RL 更像“训练它在多步任务中拿结果”。单步回答好，不代表多步任务成功。Agent 可能第一步查错工具，第二步误判异常，第三步给出看似合理但不可执行的建议。强化学习关注的是轨迹级奖励：最终是否降低延误、是否减少人工介入、是否符合安全策略。
多模态理解 则把履约现场拉进模型输入。比如门店照片、骑手上传图片、地图截图、异常凭证等，都可能帮助判断问题。来源摘要没有展开具体系统，因此这里应保持克制：可以推断多模态是履约 Agent 的重要能力，但不能把未披露的产品细节当成事实。
可以这样实践：搭一个履约异常 Agent 原型
下面是一个可改造的最小原型，用于演示履约 Agent 的基本形态：模型根据订单状态决定是否调用工具，并输出下一步处置建议。示例使用 OpenAI Chat Completions 风格接口；如果你使用其他大模型服务，只需要替换 base_url、api_key 和模型名。
运行前准备：
pip install openai
export OPENAI_API_KEY="你的 API Key"
保存为 delivery_agent_demo.py：
import json
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
ORDER_DB = {
"order_1001": {
"order_id": "order_1001",
"status": "delivering",
"eta_minutes": 18,
"promised_minutes": 10,
"rider_distance_km": 2.4,
"merchant_ready": True,
"user_message": "已经超时了，骑手是不是走错了？",
}
}
def get_order_snapshot(order_id: str) -> str:
return json.dumps(ORDER_DB.get(order_id, {}), ensure_ascii=False)
tools = [
{
"type": "function",
"function": {
"name": "get_order_snapshot",
"description": "查询订单履约状态快照，用于判断延误、距离、商家出餐等异常。",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string", "description": "订单 ID"}
},
"required": ["order_id"],
},
},
}
]
messages = [
{
"role": "system",
"content": (
"你是履约异常处理 Agent。你必须先查询订单状态，再给出建议。"
"建议必须包含：异常判断、下一步动作、给用户的话术。"
"不要承诺你无法执行的补偿或调度动作。"
),
},
{"role": "user", "content": "请处理 order_1001 的履约异常。"},
]
first = client.chat.completions.create(
model="gpt-4o-mini",
messages=messages,
tools=tools,
)
assistant_msg = first.choices[0].message
messages.append(assistant_msg)
for call in assistant_msg.tool_calls or []:
if call.function.name == "get_order_snapshot":
args = json.loads(call.function.arguments)
result = get_order_snapshot(args["order_id"])
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
second = client.chat.completions.create(
model="gpt-4o-mini",
messages=messages,
)
print(second.choices[0].message.content)
运行：
python delivery_agent_demo.py
这个例子故意很小，但它体现了生产 Agent 的几个关键约束：
- 不让模型凭空判断订单状态，而是先查工具。
- 在系统提示词里限制不可承诺的动作。
- 把输出结构化为异常判断、下一步动作、用户话术。
- 工具结果以 JSON 返回，方便后续记录、评估和回放。
如果继续向生产靠近，可以加入三类能力：
agent_runtime:
safety:
max_tool_calls: 5
require_human_approval_for:
- refund
- rider_reassignment
- user_compensation
evaluation:
offline_cases: data/delivery_incidents.jsonl
metrics:
- tool_call_accuracy
- resolution_rate
- policy_violation_rate
- user_message_quality
rollout:
mode: shadow
traffic_percent: 5
fallback: human_operator
这段 YAML 不是来源系统配置，而是一个可参考的工程骨架：先做 shadow mode，只观察不执行；再小流量灰度；对退款、改派、补偿等高风险动作加人工审批。
论文能力如何进入业务闭环
顶会论文往往关注一个明确问题：更好的训练策略、更强的推理能力、更可靠的工具调用、更稳的多模态理解。但业务系统需要的是组合拳。
一个可落地的闭环通常长这样：
- 沉淀任务集：把历史履约异常整理成可回放案例，包括输入、工具结果、人工处置、最终结果。
- 训练基础能力：用 CPT 和 Post-training 让模型熟悉业务语言、流程规范和工具格式。
- 构建 Agent 运行时：统一工具注册、权限控制、调用日志、失败重试和降级策略。
- 离线评估：用历史案例测工具选择、动作合规、话术质量和任务完成率。
- 在线灰度：先影子模式，再辅助人工，再进入低风险自动化动作。
- 反馈再训练：把错误轨迹、人工修正、用户反馈纳入下一轮数据闭环。
这里最容易被低估的是评估系统。没有稳定评估，Agent 的“自进化”可能变成自我强化错误：模型学会了讨好某个指标，却损害用户体验或业务规则。
落地时要守住的边界
履约 Agent 很有想象力，但上线时要像处理交易系统一样谨慎。
- 高风险动作必须可控：补偿、改派、取消、处罚等动作应有权限和审计。
- 工具结果优先于模型猜测：模型不能用“看起来合理”替代实时状态。
- 多模态输入要防噪声：图片、截图、定位信息可能缺失或误导，需要置信度和回退路径。
- 奖励函数不能只看短期指标：降低人工量不等于用户体验变好，压缩配送时间也可能伤害骑手体验。
- 论文方法需要工程化验证：ACL、EMNLP 论文提供方向和方法，业务落地还要经过数据、成本、延迟、安全的检验。
对工程团队来说，比较稳的采用路线是：先把 Agent 放在“建议层”和“质检层”，用真实业务流量做影子评估；当工具调用准确率、策略合规率、人工采纳率都稳定后，再逐步开放低风险自动化。这样既能吸收大模型和前沿论文的能力，也不会把履约系统的安全边界交给一次模型输出。