虾皮后端开发一面

努力拥抱AI中…1.项目拷打2.如果你要控制多个 agent，不论是 cursor、codex 还是别的工具，同时开多个的时候，你觉得会有什么问题存在？3.如果同时开 10 个、20 个，甚至更多 agent，你觉得会有什么问题？4.怎么管理它们？5.当 agent 做任务时，它不一定一次就做完，可能需要你反馈、确认、纠正。如果有十几个 agent，你怎么分配跟它们互动？6.如果要支撑这种场景，技术上应该实现哪些能力？7.你刚刚定义了 waiting、running、done 这些状态，那你觉得怎么去捕获一个 agent 的状态？8.现在像 codex 这种是独立程序，如果它没有 API，你怎么实现对它状态的获取？9.除了 hook，除了 skill 里做打点，还有什么其他方法吗？10.你有没有用过 skill 里面跑脚本这类能力？11.如果检测到 agent 一直没响应，或者卡住了，你会怎么处理？12.那是不是以后人只要对着调度器就好了？只需要做这套编排和管理？13.除了测试、复盘、对外解释结果之外，你觉得以后程序员还应该重点发力在哪些领域？怎么避免和 AI、和偏商务的人直接同质化竞争？14.你觉得有什么方法论，可以让大模型从一个非常庞大的上下文里，很精确地找到它真正需要的数据？15.你刚刚提到 RAG，这种方法在代码库场景里怎么落地？代码是怎么被切成片、变成可检索内容的？16.如果 RAG 找错了怎么办？17.Cursor、Claude Code、Codex 这类工具，面对几百万行代码、窗口又装不下的情况，这个问题怎么办？18.那你知道这些工具大概是怎么实现的吗？19.从原理上看，一种做法是先把用户提示词丢给模型，让模型决策后再搜索代码；另一种做法是先本地检索，再把结果给模型。各自有什么优缺点？

1. 自我介绍，围绕一条链路说明你做过什么、你负责什么、难点在哪2. 一个面向多业务域的 Agent 系统，为什么不能只用一个大 Agent 把所有事情做完单 Agent 的问题不是“不能做”，而是做大以后上下文会混杂，知识边界、工具边界和状态边界都不清楚。比如订单查询、风控审计、赔付建议、配置解释，本质上就是不同任务类型，它们需要的知识、状态和可调用工具完全不同。如果硬塞到一个 Agent，模型容易被无关上下文干扰，也容易误用工具。实际工程里更稳的做法是做任务拆分：入口先做路由，再把请求交给垂直 Agent 或垂直 Skill 处理。3. 对多场景、多上下文的请求做路由时，如何判断当前应该调...

我破防了

在清洁设备领域，步行式洗地机正以不可阻挡之势崭露头角，成为行业新宠。根据权威机构QYResearch（北京恒州博智国际信息咨询有限公司）的精准统计与科学预测，2025年全球步行式洗地机市场销售额已强势达到9.51亿美元，而展望未来，到2031年，这一数字有望攀升至11.68亿美元，在2025 - 2031年期间，年复合增长率（CAGR）稳定保持在3.5%。产品类型多元分类，满足多样需求。步行式洗地机根据不同的产品类型，可分为小型步行式洗地机、中型步行式洗地机和大型步行式洗地机。小型步行式洗地机灵活轻便，适用于空间相对较小、清洁区域较为分散的场所，如小型商铺、办公室等；中型步行式洗地机则在清洁效...