手搓一个催收Agent（一）：比Coding Agent难在哪？

一句话结论：催收Agent比Coding Agent更难做，因为它面对的不是编译器，而是有情绪、会反抗、会说谎的人——而且说错一句话就是合规事故。

一、Coding Agent vs 催收Agent

Coding Agent（Cursor、Devin）只需要理解代码、调用API、生成文件。输出对不对，编译器和测试用例会告诉它。

催收Agent面对的是人，而且是有情绪、会反抗、会说谎的人。

维度	Coding Agent	催收Agent
输出检验	编译器/测试用例	合规审查 + 人工审核
容错空间	报错后可以重试	说错话就是合规事故
上下文	代码文件 + 需求	用户信息 + 对话历史 + 工具结果 + 系统状态
意图识别	明确（写函数/修bug）	模糊（"知道了"可能是回避也可能是拖延）
合规要求	无	时间窗口、频次、内容、敏感职业、DNC
危机处理	无	用户说"不想活了"必须立即停止催收

核心差异：Coding Agent的输出是代码，人可以review后再提交。催收Agent的输出是话，一旦说出口就收不回来。

这意味着催收Agent的每一个组件都必须经得起生产检验，不能靠"提示词写得好一点"来兜底。

二、难在哪里：四个组件缺一不可

催收Agent的架构可以抽象为四个核心组件：

组件	催收员的对应能力	为什么难
Context	记住用户是谁、欠多少钱、上次说了什么	金额不能编造，必须从系统读取；历史对话长了会丢信息
Permissions	不能晚上打电话、不能威胁用户、不能说错金额	不是prompt里写"请温柔"就行，需要代码层硬拦截
Decider	判断用户是"真没钱"还是"不想还"	意图不只来自文字，用户不回复、点击链接不支付、承诺到期不还，都是意图
Skill + Tool	协商方案、安抚情绪、记录承诺、发送链接	Skill是策略，Tool是动作，两者不是并列关系而是"策略决定调用什么动作"

这四个组件共同解决一个问题：在严格约束下，与不可预测的人进行有效交互。

三、这个系列讲什么

这个系列共4篇文章，从业务理解出发，逐层深入技术实现：

第1篇（本文）→ 为什么催收Agent比Coding Agent难
       ↓
第2篇 → 催收员每天都在做什么（业务流程）
       ↓
第3篇 → 把流程翻译成Agent架构（Context/Permissions/Decider/Skill/Tool）
       ↓
第4篇 → 让Agent稳定运行的工程实践（提示词拆分、CoT、信息压缩）

阅读建议：

如果你不懂催收业务：按顺序读。先理解催收员怎么工作，再看怎么变成代码。
如果你已经是Agent开发者：直接从第3篇开始。业务部分可以快速跳过，重点看架构设计。
如果你想看工程实践：跳到第4篇，看提示词拆分、CoT与Compaction的具体做法。

四、技术来源

这个系列不是闭门造车，而是基于一本好书、一个好项目：

书：Chip Huyen 的 AI Engineering: Building Applications with Foundation Models

提示词拆分：不要把所有规则塞进一个巨型prompt
CoT + 自我校验：让模型先写出推理过程，再审查自己的输出
防御性提示：系统prompt会被提取，不能把敏感策略hard-code进去

项目：我自己写的 collect-agent

意图分类准确率≥90%
STOP/CRISIS关键词100%拦截
金额硬校验
敏感职业特殊处理
完整的状态机

所有文章都有对应的可运行代码。

五、下一篇

第2篇：《手搓一个催收Agent（二）：催收员每天都在做什么》

我们会跟着一个催收员走完他的一天：

早上9点，系统分配了50个M1逾期用户
第一个用户接了电话，说"我现在没钱"→ 查账单 → 了解原因 → 提供分期 → 记录承诺
第二个用户没接电话 → 发短信 → 标记静默 → 1小时后再试
第三个用户说"别再打给我"→ 立即停止 → 加入DNC
下午遇到一个律师 → 只能用标准话术 → 不能谈判

看完这篇，你会对"催收Agent要解决什么问题"有一个具体的画面。

关联

[[chatbot-exploration]] — 催收chatbot项目设计文档