北京
为什么一个AI代办demo只用二十分钟就能截图炫耀，而一旦指向真实的银行工作流，所有捷径都变成事故报告？
因为LLM本身没变，变的是我们对待它的方式。你在demo里放任的那些“小聪明”，在涉及真金白银时全成了漏洞。来看几个真实的翻车现场：
- 重复放款：代理重试了一次失败的调用，结果贷款放了两笔——没有幂等，没有状态机兜底。
- 跳过条款确认：LLM发挥创意，在客户接受协议之前就调用了
disburse，钱出去了，但客户还没点头。 - 状态蒸发：对话中途网络闪断，整个申请进度直接归零，什么都没持久化。
- PII泄漏：客户的姓名、邮箱散落在日志、追踪和向量库里——等人家要求删除时，数据早已渗入各处。
- 身份空洞：整个身份模型只有“代理人发来一个客户ID”，于是能碰到API的人就能操作任何人的贷款。
这跟LLM的能力无关，问题的根子是：你把一个概率性的文本生成器当成了可信客户端。它根本不是，它只是一个聪明但极不靠谱的实习生。围绕它的系统，得按银行对待不可靠客户端的老规矩来：硬状态机、幂等性、验证过的身份、完整的审计轨迹。
上面那个指南就是要一次性给你建好这个系统——不是那种理论综述，是一个真实的、能跑起来的工程，一条docker compose up就能在笔记本电脑上完全离线启动，你可以故意把它搞崩，看看防护怎么起效。对应的GitHub仓库里有所有操作步骤。
最终你得到的是什么？一个全功能的对话式贷款获取系统：客户跟代理聊天，挑贷款产品，看到带交互式还款图表的模拟结果，接受条款，然后收到一笔（演示用的）放款。每一步都被强制、持久化、验证、可追溯。
用户眼里，它就是一个AI聊天界面。但在界面底下，是一间麻雀虽小五脏俱全的银行。从架构底层往上看：
- 客户端到Chainlit UI：一个带真实OIDC登录（别指望那种“输入密码演示”的摆设）、持久化对话线程和Plotly还款图表的聊天界面。
- MCP宿主——LangGraph代理：一个Python代理，所有工具来自MCP服务器，内嵌确定性的贷款流程、分层槽位辅助、自改进RAG，还兼容AgentCore的
/invocationsAPI。 - MCP服务器层——loan-mcp：一个FastMCP服务器，把贷款旅程暴露为8个工具，校验调用方的身份token，把旅程绑定到调用者自己的实体上。
- 核心银行服务：四个轻量Node服务——一个编排器（XState + DBOS守护层）、一个贷款系统记录（事务外发箱）、一个无状态规则引擎（贷款策略）、一个实体API（唯一存PII的地方，按实体加密）。
- 身份平面——Keycloak：生成token，下游每一跳独立重新验证。
- 数据·事件·密钥保管：六个隔离的按服务部署的Postgres实例和对应的基础设施。
一句话总结：别再用做demo的心态给AI代理塞钱了。用这篇文章里的工程方法，把自己从事故报告的接收人，变成一个真正的生产系统建造者。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
