AI Agent工程师一面面经
完整信息
本篇目录
真题清单 & 参考回答
1. 开场意向:你偏后端工程师,还是偏 Agent 工程师?
参考回答:直接答"偏 Agent"**并补一句理由("想做端到端 AI 产品、辞职也是为深耕这个方向")
2. 运维 agent 面向多少人?怎么部署的?
参考回答:ToB 私有化叙事——不是内部工具,是卖给运营商的产品(移动/联通/电信);客户采买后由我们同事部署到客户内网,模型也部署在内网(数据不出客户环境)。
3. 两套 agent(AI 代码助手平台 vs 运维 agent)底层 runtime 是同一套吗?
参考回答:不是,两套架构——代码助手平台集成开源和内源的agent的SDK(OpenCode/OpenClaw),不单独维护 agent loop,自己做的部分是前端会话交互 + MCP 服务器开发 + skill体系;运维 agent 是自研 ReAct loop + 工具注册/调用(内部 API/脚本/命令)+ 记忆系统 + RAG。
4. 运维 agent 的 memory 模块怎么设计的?
参考回答:记忆系统分为长期/短期/外部记忆
长期 = 从对话提取的产品的事实global、用户偏好user、处理过的故障情景Episodic三类,做语义的向量化存储;记忆的存储是通过规则+llm提取,检索是通过关键词+相似度混合检索。
短期 = 用户消息/AI 消息/工具调用过程。短期记忆设置有 token 预算,达到预算的 90% 触发 map-reduce 压缩、保留最近 3 轮对话历史。
外部=根据产品文档,操作指导书创建的知识库,已经筛选沉淀的运维经验库。
5. 代码助手集成了 SDK,里面记忆有二次开发吗?
参考回答:内核的记忆能力用 SDK 自带的,opencode sdk的自动上下文压缩和记忆持久化存储,二次开发内核的收益比较低,所以除了定制插件做遥测采集,没有二次开发。
我们主要做的是会话记忆的平台化——三层会话存储:zustand 内存态(SSE 高频流式先刷内存保证 UI 连续渲染)→ 浏览器 IndexedDB(存多会话历史)+ sessionStorage(当前会话快照、防刷新秒开)→ SQLite 落盘(会话空闲/结束时,供重登/跨端拉历史)。
6.(开放性)runtime 里如果有 500~800 个 skill,怎么管理、保证上下文健康、一次调用命中该命中的?
参考回答:任何一轮决策时,skill的个数都不要超过10个,候选越多,选错的概率就越多。主要从一下两方面提高skill的使用质量:
提高命中方面: 做分层路由,将每个skill的元数据存储起来,包含名字、描述、触发词、标签等,在拼接上下文时,1)首先做规则映射,按使用场景分类分级,通过关键词、触发词命中,做粗筛;2)可以通过混合检索双路召回再做RRF融合,得到最小集后,将name、desc进入上下文给LLM做选择
治理与保证质量: 1)skill的描述是命中的基础,可以通过描述中预埋检索关键词来保证skill的路由正确,规范的命名与描述(做什么,使用场景,什么场景不用)来保证命中正确;2)相关skill可以做合并,命中后再在子集中展开;3)低频、废弃的skill不进路由池,新增skill要保证不影响原有命中率;4)通过数据飞轮持续迭代优化 description
7. 底层 opencode 的 memory 模块是怎么设计的?
参考回答:采用的是 opencode 原生的记忆能力
1)指令层,用的AGENTS.md,分为全局的和项目级,且兼容CC的CLAUDE.md做兜底。这部分是跨会话的记忆,每次都要拼到system prompt中。
2)会话层,采用SQLite持久化存储,按照session隔离,包含session、message、part、event等
3)压缩层,默认会话上下文达到阈值触发压缩,根据配置的保留token或者turn,进行head和tail的切分,对head进行增量压缩;支持配置裁剪,会扫描旧的工具输出,发给大模型时占位符标记,从而减少token占用
8. Skill 的自我优化/自我演进,一般怎么设计?(全场最大空白)
参考回答:
1)复核与淘汰:skill 注册中心加两个计数字段——每次 skill 被调用,从执行结果反推 helpful / harmful(处置成功且流程吻合 → helpful+1;miss 分析里被选错或误导 → harmful+1)。长期 harmful 占比高的 skill 自动降权、移出候选池,并进入人工复审队列。
2)给 skill 调用埋点——命中哪个、任务是否完成、结果被采纳还是被纠错/回退;对话结束后,根据轨迹产出skill path:诊断报告 + 定位到具体 skill 的具体章节 + ADD/UPDATE/REMOVE 补丁。(重写的话llm倾向于删细节保简洁,往往效果更差)。补丁要过两道闸门才生效——评测集回归,使用skill命中评测集,保证补丁不能劣化任何已有命中+ HITL 审核。通过后版本化上线,旧版标记后保留,审计记录使用的版本。
3)批量归纳:参考 Trace2Skill 的做法,定时任务扫描案例记忆,把多次相似失败批量归因——“最近 20 次 XX 集群磁盘告警处置,15 次都在同一步走错”,一次改写,而不是逐条打补丁,多条轨迹都踩得坑写成通用规则,偶发情况丢弃。
9.(前沿敏感度)Pi Agent / Hermes / DeepSeek Harness 这些有了解吗?
参考回答:可以讲 Pi Agent 的极简设计、Hermes的自进化闭环、CC的基建(比如三级压缩机制)、DSH的插件模式。总之要有自己对某一块设计的理解。
10. OpenClaw 和 OpenCode 的区别?
参考回答:对"两个相近框架差异"的题,先锁定比较维度再作答
定位: OpenClaw是AI执行网关,目标是在通信软件中发一句话,agent就在电脑上整理文件、跑脚本,开发场景是它的众多场景之一;opencode是纯粹的编码agent,对标cc,所有设计都是围绕读懂代码、改代码、跑测试这条链路。
架构: openclaw是星型网关架构,一个gateway守护进程18789常驻后台,负责消息路由、会话隔离;opencode是C/S架构,agent内核跑在本地server里,tui是其中一个客户端,桌面应用、ide插件都能连同一个server,可以跑在服务器上。
记忆系统: OpenClaw记忆以纯md存在本地,每次对话主动加载;检索用向量语义+BM25混合方式,上下文快满时会在压缩前出发memory flush;OpenCode的记忆是会话级的,使用sqlite进行存储,摘要压缩+可选修剪。
本篇目录
当前问题0112
- 01
**1. 开场意向:你偏后端工程师,还是偏 Agent 工程师?**
- 02
**2. 运维 agent 面向多少人?怎么部署的?**
- 03
**2. 运维 agent 面向多少人?怎么部署的?**
- 04
**3. 两套 agent(AI 代码助手平台 vs 运维 agent)底层 runtime 是同一套吗?**
- 05
**4. 运维 agent 的 memory 模块怎么设计的?**
- 06
**5. 代码助手集成了 SDK,里面记忆有二次开发吗?**
- 07
**6.(开放性)runtime 里如果有 500~800 个 skill,怎么管理、保证上下文健康、一次调用命中该命中的?**
- 08
**6.(开放性)runtime 里如果有 500~800 个 skill,怎么管理、保证上下文健康、一次调用命中该命中的?**
- 09
**7. 底层 opencode 的 memory 模块是怎么设计的?**
- 10
**8. Skill 的自我优化/自我演进,一般怎么设计?(全场最大空白)**
- 11
**9.(前沿敏感度)Pi Agent / Hermes / DeepSeek Harness 这些有了解吗?**
- 12
**10. OpenClaw 和 OpenCode 的区别?**