面灵AI→

蚂蚁二面:Agent Runtime、读写鉴权与 AI Native 转型

轮次
二面
时间
2026-09
来源
牛客网

《面试题目》

  1. 介绍一下最近做的 AI 相关项目,你们的 Agent Runtime 是怎么设计的?
  2. 知识库和 Skills 分别承载什么内容?如何验证它们能够覆盖业务的真实使用场景?
  3. Agent 的读操作和写操作分别如何鉴权与控制风险?为什么写操作最终仍要跳转工单由用户确认?
  4. 在长任务中,如何通过 Plan 避免 Agent 盲目调用工具和丢失全局方向?
  5. 你的实习时间有多长?
  6. 如果继续推进一年的 AI Native 化建设,你认为应该分哪些阶段、重点做哪些事情?
  7. 如何补齐平台能力的 CLI 与 Skills 暴露,并将前端交互改造成以 Agent 为中心的模式?
  8. 团队的研发、测试、验收和沟通流程如何进一步向 AI Native 转型?
  9. 如果业务方只提供服务目标和流量意图,由 Agent 全面托管后续操作,你会如何设计这套系统?
  10. 面向具体业务自研 Agent,与基于通用 Base Agent 开发插件,各有什么优缺点?
  11. 如何看待工具、记忆、权限管理和 Agent Loop 全面插件化的发展趋势?
  12. 为什么没有留在原团队转正?
  13. 你的职业规划是什么?为什么希望继续从事 Agent 和 AI 应用开发?

《参考解析》

Agent Runtime 该有哪些模块

按一次会话的生命周期拆:模型接入与路由(多模型、配额、降级)、上下文与记忆管理(system prompt、历史压缩、检索、长期记忆的写入与遗忘)、循环调度(状态机、步数与预算、并发)、工具执行层(注册表、参数 schema、沙箱、超时、幂等)、权限与审计(谁在什么资源上做了什么)、可观测(trace、token 与成本、失败归因)、评测与回归、插件化的扩展点。判断 Runtime 设计好坏的一条标准是:业务方接新能力时,是只写一个工具或 Skill,还是又要改循环和状态管理。

知识库与 Skills 的分工及覆盖验证

知识库承载事实性的、可检索的、会随时间更新的语料,解决「知道什么」;Skills 承载流程性的、可执行的能力封装,解决「怎么做」,里面可以包含工具编排、领域规则、示例和验收标准。覆盖验证不能靠感觉:从线上真实请求和工单里采样出用例集,按业务线和高频意图分层,定期跑通过率并做人工抽检;同时盯住两个反向指标——兜底率(走到兜底话术或转人工的比例)和未命中率,它们直接指出知识库或 Skill 的缺口。新增的能力要回灌进用例集,形成回归。

读写操作的鉴权与风险控制

读操作风险可控,走最小权限加数据分级:按用户和租户过滤数据、敏感字段脱敏、记录查询审计、对大批量拉取做条数与频率限制,通常可以自动执行。写操作不可逆,必须两段式:Agent 先产出变更方案(改什么、影响面多大、怎么回滚),再经过权限校验(RBAC/ABAC 加资源归属加影响面评估),高风险动作挂起等人工确认。最终跳工单的理由要说透:一是责任可追溯,二是审批链本来就在既有系统里,三是失败要能回滚,四是避免 Agent 持有一把「什么都能改」的万能凭证。配套还要幂等键、变更前快照、变更后校验。

长任务里 Plan 的作用

Plan 是给 Agent 的外部记忆和方向锚点:先产出一份显式计划,每一步写清目标、预期产物和校验方式;每执行完一步就回写状态,而不是把全部历史塞回上下文。这样能避免两类典型故障——上下文被中间步骤稀释后反复调同一个工具,以及为完成局部目标而偏离全局。工程上还要加偏离检测:定期拿当前状态和 Plan 对齐,必要时 replan;同时设步数与成本上限,防止边做边加需求。

AI Native 建设分几个阶段

可以分三步:第一阶段单点提效,Copilot 化,人主导,让 AI 写代码、写单测、写文档、读陌生代码库;第二阶段流程自动化,把平台能力 CLI 化和 Skill 化,让 Agent 能真正调用系统,关键路径配上自动校验和回滚;第三阶段目标托管,业务方只给服务目标和流量意图,Agent 自主规划执行,人只处理审批和例外。每一阶段的配套都不一样:第一阶段靠个人习惯,第二阶段要有可观测、评测、权限和数据口径,第三阶段还要有 SLO 体系、例外处理流程和责任边界。把平台能力暴露出去的做法是先做成稳定的 CLI/Skill——幂等、可脚本化、有明确退出码和结构化输出,再把前端交互改成以 Agent 为中心的对话入口,界面退化为确认和可视化。

自研 Agent 还是基于 Base Agent 做插件

自研的好处是贴合业务、可以深度优化、完全可控;代价是重复造轮子,循环、记忆、权限、可观测都要自己维护,能力上限受团队规模限制。基于通用底座做插件上手快、能跟着平台升级、复用成熟能力;代价是受底座的抽象约束,定制困难,出问题要跨团队排查。选择依据是差异化在哪里、迭代速度要求多高、团队有多少人、有没有合规约束。关于工具、记忆、权限、Loop 全面插件化:本质是把 Agent 的能力供给标准化,收益是复用和生态,风险是抽象泄漏与版本耦合,所以契约定义和兼容性管理比插件本身更重要。

职业规划与动机类问题

「为什么不留原团队转正」和「为什么继续做 Agent」这类问题,考的是动机是否真诚、规划是否自洽。回答要落到具体的事上:在原团队做了什么、为什么想换环境、这段经历让你想在 Agent 方向继续深入什么。避免贬低前团队,也避免空喊「看好 AI 前景」。