行业垂直Agent

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

1.最近做 Agent 时，我最大的感受是：一个真正可跑的Agent应用，无论是B端还得C端产品，最耗时间的往往不是模型能力，而是接入链路。登录认证、权限控制、多协议对接、企业身份源接入、工具服务边界管理……这些事情单看都不难，但一旦分散在各个服务里，开发和维护成本会越来越高。2.但是最近在GitHub上找到的一个项目Casdoor，成熟高效的一站式解决了这些问题。官网:https://casdoor.ai/GitHub:https://github.com/casdoor/casdoorCasdoor主要拥有这些能力：统一身份与组织管理（Web UI 可视化）标准协议支持：OAuth/OIDC/SAML/CAS/LDAP/SCIM安全能力：MFA、WebAuthn、TOTP、审计日志AI 场景：MCP Gateway、A2A 相关接入能力开发友好：API + 多语言 SDK，方便快速落地3. 使用Casdoor之后最大的价值就是:  新应用接入更快，少走很多重复流程Agent/AI 服务调用边界更清晰安全策略集中管理，不再散落在各处团队协作成本和排障成本都下降了如果你也在做 AI 产品或 Agent 平台，这个项目非常值得看https://github.com/casdoor/casdoor

时长:30min(应该是我比较菜)自我介绍，对Agent项目拷打20min，几个关键问题没有回答的很好，这时候就感觉寄了。回答的不太好的问题。1.整个系统为什么这么设计，解决了什么问题？之前的方法没有解决吗？2.短期记忆具体是怎么用的，效果怎么测？3.怎么判断上下文过长，具体?一些知识性考察：1.Deepseek是怎么做负载均衡的？2.设计一个Agent要考虑哪些方面，怎么设计？

27届双非学院本，想在暑假找一个实习，看到现在的简历大部分都是agent的了，像我这种还没学的还能找到实习吗