Agent 项目最常见的事故，是上线前靠感觉调 prompt，上线后靠用户投诉发现问题。模型换了、工具改了、知识库更新了，没人知道效果从哪天开始变差。
Coze Loop 是面向 AI Agent 优化的平台，覆盖开发、调试、评测、Prompt 管理和线上监控。它的价值不是多一个控制台，而是让 Agent 的质量变化能被记录、比较和回滚。
Docker Compose 快速部署
克隆项目：
git clone https://github.com/coze-dev/coze-loop.git
cd coze-loop开发或快速体验：
make compose-up部署前需要配置模型信息，重点看：
release/deployment/docker-compose/conf/model_config.yaml不要把真实模型 key 写到公开仓库里。内部部署建议用环境变量或 Secret 注入。
Kubernetes 部署路线
如果团队已有 K8s，可以走 Helm：
helm pull oci://docker.io/cozedev/coze-loop --version 1.0.0-helm
tar -zxvf coze-loop-1.0.0-helm.tgz
cd coze-loop
make helm-up
make helm-pod
make helm-logf-app
make helm-logf-nginx对外网部署要先做安全评估。评测平台会存 Prompt、样本、输出和可能的用户数据，不能裸奔。
先建评测数据集
不要一上来就接线上流量。先建一个最小评测集。
{
"case_id": "refund_001",
"input": "订单超过 30 天还能退吗",
"expected_behavior": "说明规则，并提示特殊情况需要人工处理",
"must_include": ["30 天", "人工"],
"must_not_include": ["一定可以", "保证退款"]
}评测集可以从历史工单、真实问答、人工设计边界题里来。关键是覆盖失败场景，不要只放简单样本。
Prompt 要版本化
每次改 prompt，都要记录版本、改动原因和评测结果。
prompt version: support-agent-v12
change: 增加退款场景的人工升级条件
eval result: pass rate 86% -> 91%
risk: 回复变长，需要观察用户满意度没有版本记录，Prompt 优化就会变成玄学。今天改好，明天改坏，谁也说不清。
线上监控看什么
最少看五个指标：
任务成功率
人工接管率
格式错误率
平均响应时延
单次任务成本如果是工具型 Agent，还要看工具调用失败率和超时率。很多 Agent 失败不是模型回答差，而是工具链路不稳。
把评测接入发布流程
比较稳的流程是：
修改 Prompt 或模型配置
-> 跑离线评测
-> 低风险流量灰度
-> 观察线上指标
-> 全量发布或回滚Agent 质量闭环不是一次性工作。模型会更新，业务会变化，用户问法会漂。没有持续评测，迟早靠运气。
Coze Loop 适合把这些环节收进一个平台里。它不替你判断业务对错，但能让每次调整都有证据。Agent 想长期跑，靠的就是这套证据链。
评测指标要分自动和人工
自动评测适合格式、关键词、规则覆盖、工具调用是否成功。人工评测适合语气、业务判断、风险边界。两者不要互相替代。
auto: JSON 格式正确率、必须字段、禁止承诺、工具成功率
human: 是否真正解决问题、是否过度自信、是否符合品牌语气Coze Loop 这类平台能帮你把评测流程跑起来，但评测标准还得业务团队和工程团队一起定。
线上样本要回流
上线后，最有价值的数据来自真实失败。用户点踩、人工接管、工具失败、超时任务，都应该进入样本池。
线上失败样本
-> 脱敏
-> 标注原因
-> 加入 dev 或 test 集
-> 评测新版本这个回流闭环跑起来，Agent 才会越用越稳。
不要只优化平均分
平均分提升可能掩盖高风险样本退化。每次改模型或 prompt，都要单独看关键场景：退款、投诉、隐私、合规、财务、医疗建议等。
Agent 的质量不是总分游戏。真正要防的是那些低频但高代价的错误。