快手 AI 应用服务端秋招三面：分布式 Agent、通信与 Lua
本场面试题
- 这个 Agent 项目为什么需要分布式设计？
- Agent 与 Agent 之间怎样通信？
- 分布式 Agent 遇到异常后，怎样保障稳定性？
- Lua 脚本包裹太长的业务逻辑，会有什么问题？
面经与参考答法
快手 AI 应用服务端秋招三面：分布式 Agent、通信与 Lua
公司：快手；方向：AI 应用服务端；招聘场景：秋招；轮次：三面。标题只给“9.09”，没有面试年份；作者自述本轮30多分钟。
根据候选人公开自述选录技术问题，经历未获外部认证。原帖未提供完整现场答案；下方短答与例子均为编辑补充，不代表作者实际作答、项目实现或企业标准答案。本文选录4组问题。
（1）这个 Agent 项目为什么需要分布式设计？
先给出单进程或集中式编排的基线，再说明是否存在独立扩容、长任务执行、故障隔离或跨机器资源需求。多个 Agent 角色并不必然需要分布式部署；只有收益能覆盖网络、状态一致性、重试与运维成本时才拆分，并用相同任务与预算比较成功率、延迟和资源占用。
教学例子：大量互不依赖的仓库分析任务可由独立 Worker 扩容，但计划和完成状态仍要有权威存储；只有几个紧密依赖的步骤时，先用一个进程加受控并行可能更简单。
知识阅读：多智能体协作与适用边界。
（2）Agent 与 Agent 之间怎样通信？
按调用时长和依赖选择同步请求或异步消息，再定义任务、消息、父运行、尝试次数、版本和结果引用等字段。通信层确认收到消息，与业务层确认任务完成分开；接收方校验来源、权限和格式，处理重复及迟到结果。下游依赖上游时，结果通过校验后才解锁后续任务。
教学例子：B必须读取A的分析结果，队列返回ACK只能说明消息被接收；协调器还要等到A返回对应任务与版本的成功结果，不能收到ACK就让B使用空内容。
知识阅读：多智能体消息、协议与状态同步。
（3）分布式 Agent 遇到异常后，怎样保障稳定性？
先区分网络瞬断、限流、参数错误、权限拒绝和副作用未知，再决定等待、修参、有限重试或终止。把任务状态和可信结果持久化，重试共享总超时与预算；写操作保留稳定幂等标识。进程恢复时从可信检查点继续，外部动作结果未知则先查询对账，不能捕获异常后盲目重发。
教学例子：工具请求超时但下游可能已创建记录，先用操作ID查实际状态；若已创建便回收结果，无法判断则保存未知状态并升级处理，避免生成第二份记录。
知识阅读：失败分类、重试、补偿与恢复。
（4）Lua 脚本包裹太长的业务逻辑，会有什么问题？
代码长不等于执行慢。先确认脚本宿主，再测输入规模、实际计算、内存与宿主调用成本；协程是协作式让出，不自动获得抢占或并行。宿主预算、检查点或独立进程隔离分别控制不同风险，终止执行也不自动撤销外部效果。
教学例子：几行双重循环也可能随输入平方增长；同步宿主线程被占用时会拖延该线程的其他工作。可将计算拆成有界批次，在宿主支持的边界让出并检查取消，同时保持输入版本和提交条件。原文没有给出宿主，不能默认使用 Redis；只有明确是 Redis 服务端脚本，才另外讨论阻塞其他客户端、BUSY 和写入后的终止限制。