25届网安专升本鼠鼠

这是我的第一版简历,现在简历改动也不是很大(主要加了java安全的东西、实习经历和格式改变了一下)。

25届,专升本三本鼠鼠,黑盒太菜了梭哈了java安全,23年主要边玩边学学了大半年java开发(se javaweb ssm springboot ),顺便跟了cc链。今年5月开始写博客,java安全需要学的东西也多的一匹,慢慢学了:shiro,jndi,rmi,servlet-api内存马,高版本下Tomcat回显。

最近主要学agent内存马和java代码审计,fastjson没学。主要现实中没有学习圈子,一个人学,看各位师傅的博客,一个问题可能需要很久才能解决。内网也很久没学了,没实践过,感觉忘得差不多了。到现在简历都不敢投怎么办啊(之前暑假的时候投了长亭实习,一面官网过了,二面没消息,也没显示挂,估计无了,贼想去的一家公司)。

另外学校还必须上两个月课,我问了辅导员走不掉,这个对秋招有影响么?有老哥给给建议么?
全部评论
挖的用友是通用漏洞吗
点赞 回复 分享
发布于 2024-08-22 14:35 北京
感谢分享
1 回复 分享
发布于 2024-08-19 22:07 黑龙江
现在大佬怎么样了
点赞 回复 分享
发布于 2024-08-28 09:02 青海

相关推荐

03-18 10:30
已编辑
阿里巴巴_淘宝_前端
// 淘天 27 届暑期实习生正在招聘 各方向都有海量 HC 欢迎看我置顶帖子投递最近在帮部门看简历,发现不少同学在做项目时都挂了 Agent 的标签。但在面试过程中,很多同学对这个方向的理解还停留在调用API的层面,稍微深挖一下架构设计就接不住了。整理了一个最近面试中比较高频的Agent技术问题,大家可以先试着回答一下,看看基础扎不扎实:---一面 | AI Agent 架构设计面试题:请设计一个支持多工具调用的 ReAct Agent,说明其核心循环、工具调度策略、以及如何处理多步推理中的错误恢复。---参考答案一、ReAct 核心循环ReAct 的本质是一个 思考 → 行动 → 观察的迭代循环。Agent 在每一步先进行推理(Thought),分析当前状态和已有信息,决定下一步该做什么;然后执行行动(Action),选择一个工具并传入参数;最后获取观察结果(Observation),把工具返回的信息追加到上下文中,进入下一轮循环。直到 Agent 判断已经获得足够信息,输出最终答案。与纯 Chain-of-Thought 的核心区别:CoT 是闭卷考试,Agent 是开卷——每一步推理都可以与外部世界交互,用真实数据修正推理方向,而不是纯靠模型内部知识"硬猜"。二、工具注册与调度工具如何让 LLM "认识":每个工具以结构化方式注册,包含名称、功能描述、参数定义(类型、是否必填、含义说明)。这些信息会被注入到系统提示词中,LLM 通过理解这些描述来决定何时调用哪个工具、传什么参数。工具描述的质量直接决定了 Agent 的调度准确率——描述模糊,模型就会选错工具。三种调度策略:- 串行调用:每次只调一个工具,等到结果后再决定下一步。适合步骤之间有依赖关系的场景,比如"先查订单号,再根据订单号查物流"。- 并行调用:一次推理中输出多个工具调用,并发执行。适合多个独立子任务,比如"同时查北京天气和上海天气"。- 规划-执行分离:先让 LLM 生成一个完整的多步计划,再逐步执行每一步。适合复杂任务需要全局视角的场景。生产环境通常是混合策略:Agent 动态判断当前步骤是否有可并行的操作,有则并行,否则串行。三、错误恢复机制工具执行失败:核心原则是**不要在工程侧硬编码恢复逻辑**。工具失败后,应该把错误信息作为 Observation 原样返回给 LLM,让模型自己决定下一步——是重试、换个工具、还是换一种思路绕过。这恰恰是 Agent 相比传统程序的核心优势:用 LLM 的推理能力应对非预期情况。当然,对于网络超时这类瞬时错误,工程侧可以做有限次数的自动重试,但逻辑层面的恢复应该交给模型。推理陷入死循环:Agent 可能反复执行相同的操作却期待不同结果。需要一个循环检测机制:对比最近几步和之前几步的行为模式,如果工具调用和参数完全重复,就往上下文中注入一条引导信息,提示模型"你在重复相同操作,请尝试不同方法"。同时设置全局最大迭代次数作为硬性兜底。上下文窗口溢出:这是多步推理中最现实的工程问题。每一轮循环都会往上下文里追加 thought + action + observation,几轮下来就可能撑爆窗口。常用解法:对早期步骤做摘要压缩只保留关键结论,对过长的工具返回结果先截断或提取摘要再存入历史,以及每隔几步让 LLM 自己总结"到目前为止的关键发现"。四、生产级可观测性上线不是终点。一个可靠的 Agent 系统需要:完整的 Trace 记录(每一步的推理、行动、观察),Token 消耗监控(防止成本失控),任务维度的成功率和平均步数统计,以及超过最大步数后降级到人工处理的兜底机制。---追问 Q&AQ1:多 Agent 协作时,如何设计 Agent 之间的通信和协调机制?A:主流有两种模式。Supervisor 模式(中心化):一个"主管 Agent"负责接收任务、拆解子任务、分配给专项 Agent,然后汇总各 Agent 的结果做最终决策。好处是流程可控、容易调试,缺点是主管 Agent 成为单点瓶颈,它的推理能力决定了整个系统的上限。去中心化消息传递:多个 Agent 通过共享的消息总线或黑板系统通信,每个 Agent 监听自己关心的消息类型,处理后将结果发回总线。好处是扩展性强、不存在单点瓶颈,缺点是调试困难、消息顺序和冲突处理复杂。实际工程中更常见的是分层混合架构:顶层用 Supervisor 做任务编排,底层的子任务内部允许 Agent 之间点对点通信。这样兼顾了全局可控性和局部灵活性。一个经常被忽略的关键设计点是共享上下文管理:多个 Agent 看到的"世界状态"如何保持一致?通常会设计一个共享的 State 对象,所有 Agent 只能通过定义好的接口读写状态,避免并发冲突。---Q2:Agent 的短期记忆和长期记忆应该如何设计和配合?A:本质上对应两种不同的信息需求。短期记忆就是当前对话的上下文窗口,存放的是本次任务的推理过程和中间结果。它的特点是时效性强但容量有限。核心挑战前面说过——窗口溢出管理。长期记忆是跨会话持久化的知识,通常用向量数据库实现。每次对话结束后,把值得记住的信息(用户偏好、历史决策、领域知识)向量化后存入。下次对话开始时,根据当前问题做相似性检索,把相关的长期记忆注入到系统提示词中。两者的配合策略:Agent 在每一轮推理前,先从长期记忆中检索与当前任务相关的历史经验("上次处理类似问题时用了什么方法"),注入到上下文中作为参考。短期记忆负责当前任务的连贯推理,长期记忆负责跨任务的知识积累。一个常见的坑是记忆污染:把错误的推理结论写入了长期记忆,导致后续任务反复犯同样的错。所以写入长期记忆前需要有质量校验机制,比如只有任务成功完成时才写入,或者由另一个 LLM 评估该记忆是否值得保留。---Q3:如何防止 Prompt Injection 导致 Agent 执行恶意工具调用?A:这是 Agent 安全中最核心的问题。攻击面在于:Agent 处理的用户输入或工具返回的外部数据中,可能嵌入了恶意指令,诱导 LLM 执行非预期操作。防御需要多层:第一层:输入隔离。 用户输入和系统指令必须在提示词中明确分隔,使用结构化标记区分"这是系统指令"和"这是用户数据"。避免用户输入被模型当作指令执行。第二层:工具权限分级。不同风险等级的工具设置不同的调用条件。只读查询类工具可以自由调用,但涉及写入、删除、发送等不可逆操作的工具,需要额外的确认机制——比如二次 LLM 审核(用另一个独立的模型判断"这次调用是否合理"),或者直接要求人工确认。第三层:输出过滤。工具返回的外部数据在进入 Agent 上下文前,先做清洗,去除可能被解释为指令的内容。第四层:行为监控。对 Agent 的工具调用模式做异常检测。比如一个处理客服问题的 Agent 突然开始调用文件系统工具,这明显异常,应该立即阻断并告警。没有银弹,必须纵深防御。---Q4:如何评估一个 Agent 系统的效果?和评估单次 LLM 调用有什么区别?A:区别很大。单次 LLM 调用的评估是静态的——给输入、看输出、算指标。但 Agent 是一个多步动态过程,同一个最终结果可能有完全不同的路径质量。Agent 评估需要看三个维度:结果维度:任务是否完成、最终答案是否正确。这和评估普通 LLM 类似。过程维度:用了几步完成(效率)、有没有冗余操作(比如查了不需要的信息)、有没有走弯路后自我纠正(鲁棒性)。两个 Agent 都答对了,但一个用了 3 步另一个用了 15 步,质量完全不同。成本维度:总 Token 消耗、工具调用次数、端到端延迟。在生产环境中,这直接决定了系统是否可用。评估方式上,通常会构建一个 benchmark 数据集,包含不同难度的任务和标准答案。让 Agent 跑一遍,同时记录完整 trace。然后用自动化指标(完成率、平均步数、Token 消耗)加人工评审(推理路径是否合理)综合打分。
查看5道真题和解析
点赞 评论 收藏
分享
嘿,27届的学弟学妹们:我是你们一个“老”学长,15毕业,现在在阿里十年了。很多人问我当年是怎么进来的——说实话,不是靠秋招海投,也不是靠竞赛奖项堆出来的简历,而是研二暑假的一段实习。那时候AI还没现在这么火,但阿里已经很看重“能不能上手干活”。我那会儿在学校做过几个小网站,代码写得糙,算法题也刷得不多,但因为暑假在一个创业公司实习过两个月,参与了一个真实上线的后台系统开发,面试官觉得“这小子能干活”,就给了我机会。十年过去了,技术变了,风口变了,连办公室都从西溪园区搬了好几次,但有一点没变:大厂招人,还是特别看重你有没有真刀真枪干过活。尤其是现在——AI满天飞,大模型、智能推荐、AIGC工具层出不穷,听起来高大上,但落到实际业务里,拼的还是你能不能把技术用起来、跑通链路、解决真实问题。而这些,光靠课堂作业和LeetCode是练不出来的。实习不是“打杂”,是你离真实世界最近的跳板我知道有些同学觉得:“实习就是端茶倒水、写写文档,学不到东西。”但我想说,那可能是你没找对地方,或者没主动争取。我带过不少实习生,有的来了两周还在配环境,有的第一周就参与需求评审、第二周就提PR上线。差别在哪?不是能力,是态度+机会。举个例子:去年隔壁组有个实习生,研二,学校一般,简历也不亮眼。但他提前自学了LangChain和FastAPI,来之前自己搭了个小助手demo。来了之后,刚好团队在做智能客服的语义理解模块,他就主动接手了一个子任务——优化意图识别的召回率。三个月下来,不仅代码合进主干,还写了技术复盘文档。最后直接拿了转正offer。你看,不是名校光环决定一切,而是你有没有带着“解决问题”的脑子去实习。为什么27届现在就要行动?很多同学觉得:“我才大三、才研二,急什么?”但现实是:大厂暑期实习招聘,往往在你上学期就开始了!比如字节、腾讯、阿里这些公司,每年9月到次年3月是暑期实习黄金投递期。热门岗位(后端、算法、AI工程等)几百人抢一个坑,如果你等到研三才开始准备,连入场券都拿不到。而且实习不只是为了拿offer,更是为了试错:你以为喜欢算法,结果发现天天调参很枯燥;你以为前端只是切页面,结果发现要懂性能、懂体验、懂跨端;你以为AI很酷,结果发现80%时间在清洗数据、对齐需求……早点实习,早点知道自己适合什么,秋招时才能精准发力。天猫核心行业技术团队春招实习开始了,名额确实不多,看到的可以冲了~https://www.nowcoder.com/jobs/detail/438705?jobId=438705
校招求职吐槽
点赞 评论 收藏
分享
评论
9
3
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务