启元机器人软件平台开发一面：转账 Agent 的槽位、幂等与稳定性

《面试题目》

1. 自我介绍。
2. 项目是实习产出、自用练手还是对外提供使用？
3. 意图识别、槽位提取、多轮补全怎么落地：以「帮我汇一万块给我上一次转账的人」为例，讲完整处理流程；最终是语义转指令还是推表单给用户填写？
4. 该场景属于 Agent 吗？和直接在 APP 点击转账操作的区别是什么？
5. 以「给张三转 1 万 2」为例，哪些信息可自动填充、哪些信息缺失需要补充？
6. 多轮对话补齐信息，会不会比直接页面操作更复杂？
7. Tool Calling 如何动态选择工具、构造入参、路由分发，举实例；涉及哪些业务规则？
8. 如何判断涉密国家？举例：境外开户人长期在国内生活，向境外账户转账的判定逻辑。
9. 工具调用失败、无法自动执行时兜底策略是什么？
10. 兜底方案里，如何避免重复转账，保证幂等？讲一下唯一 ID 的实现过程。
11. 多模态结构化信息提取怎么做？报关单、合同、发票这类文档，单图片 / PDF 怎么处理？OCR 是调用外部接口还是自研？
12. 在这个 Agent 项目里，你本人独立负责做了哪些工作？
13. AI 辅助表单是否由你开发？后端 / Agent 拿到 OCR 结果后，怎么完成前端页面表单填充？
14. 个人练手项目里，最有挑战的问题是什么？怎么解决、用到哪些技术？
15. 自研项目提到高并发、抢占库存、一人多单，如何验证该场景？
16. 使用 JMeter 做并发测试，具体怎么模拟并发？
17. 项目服务部署在哪里？是否本地部署，本地 JMeter 压测？
18. 搭建一个完整 Agent，需要重点关注哪些方面？
19. Agent 稳定性、安全性从哪些维度保障？上线前如何测试验证？

《参考解析》

「语义转指令」还是「推表单」，取决于风险等级，不是技术炫技。 转账这类资金操作，正确做法是「模型负责理解，表单负责确认」：模型把自然语言解析成结构化意图（付款人、收款人、金额、币种、附言），缺什么补什么，最后把填好的表单推给用户确认，用户点确认才真正提交。全自动执行只适合低风险、可逆、幂等的动作（查余额、查汇率）。这样设计的原因很直接：模型会幻觉，金额和收款人错一位就是资损，必须有一个确定性的人工确认点。多轮补全确实比点页面「更复杂」，但它解决的是另一类场景——用户说不清、不想找入口、或手上不方便操作；产品上要允许用户随时切回表单，而不是把对话做成唯一路径。

槽位补全要有「必填 / 选填 / 可推断」三类。 以「给张三转 1 万 2」为例：金额和收款人可以确定；付款账户、币种、到账方式、附言可能缺失或有默认值。可自动填充的是有明确默认且低风险的项（默认借记卡、常用币种、上次使用的附言）；必须追问的是影响资金去向的项（具体哪张卡、是否跨境、收款账号是否完整）；可以由系统推断的要标注来源并让用户确认（「张三」对应通讯录里的哪一位、是否同名多人）。追问要一次问一项、给出可选项，别一口气甩五个问题；用户改口时要能回退已填槽位，而不是把新旧值混在一起。

Tool Calling 的关键不在「能调」，在「调哪个、参数怎么来、失败怎么办」。 工具选择一般走「意图分类 + 工具描述检索 + 模型决策」三层：先按业务域缩小候选，再把工具的用途、参数 schema、适用条件放进上下文让模型选，最后本地校验参数。路由分发要有确定性规则兜底：命中明确指令（「查汇率」）直接走对应工具，不让模型自由发挥；涉及多工具编排时，先规划再逐步执行，每一步的中间结果落状态。业务规则要写在工具内部而不是提示词里：限额、白名单、涉密国家、反洗钱规则，都是代码里的硬校验，模型无权绕过。像「境外开户人长期在国内生活、向境外账户转账」这种判断，依据应是收款行所在国家/地区、账户属性、交易币种和监管名单，而不是开户人当前所在地；规则要能解释、能审计、能配置。

幂等是资金类 Agent 的生命线。 唯一 ID 不能只用「用户 ID + 时间戳」，要在「业务意图」层面生成：客户端每次发起转账生成一个 request_id（UUID/雪花），重试时复用同一个；服务端以 request_id 建唯一索引，插入成功才继续，重复请求直接返回第一次的结果。更稳的是「幂等表 + 状态机」：INIT → VALIDATED → SUBMITTED → SUCCESS/FAILED，每次状态流转带版本号做乐观锁；调用下游银行接口时把 request_id 作为对方的分笔流水号，确保跨系统也只扣一次。超时不能当失败处理——先查状态，确认没成功再重试；对账任务兜底扫描「长时间处于 SUBMITTED」的单子。测试时要专门注入「请求已到达但响应丢失」的场景，验证不会重复扣款。

Agent 上线前要按「能力、稳定、安全、成本」四张表验收。 能力：固定评测集 + 真实 badcase，按意图、槽位、工具选择、最终答案分层算准确率；稳定：超时、限流、下游 5xx、模型返回非法 JSON、工具连续失败，逐项做故障注入，看是否降级而不是崩；安全：提示词注入、越权工具调用、敏感信息泄露、危险操作确认，必须有一票否决的用例；成本与延迟：P95 延迟、单次任务 token/工具调用次数、失败重试放大。高并发验证别只在本地 JMeter 压——本地压测受网络和机器限制，数字好看但不代表线上；要区分「压接口」和「压业务链路」，用固定数据集、逐步加压找拐点，同时看数据库连接池、下游限流和 GC。JMeter 模拟并发时，线程组要配 ramp-up、思考时间、CSV 参数化，断言不仅看响应码还要校验业务结果，否则「全 200 但库存扣成负数」也会被当成通过。