蚂蚁 AI Agent开发一面(暑期)

1. 自我介绍

2. 项目拷打

3. 你怎么理解现在的大语言模型，它和传统 NLP 系统最大的分水岭是什么

现在的大语言模型本质上不只是一个“更大的文本分类器”或者“更强的生成器”，而是把表征学习、任务迁移和自然语言接口统一到了一个模型里。传统 NLP 往往是一任务一模型，文本分类、命名实体识别、问答、摘要各做各的，大模型则是在大规模预训练后，通过提示、工具调用、少样本样例甚至简单微调完成大量任务迁移。真正的分水岭不在参数量，而在它具备了统一接口、上下文学习和任务泛化能力，所以很多原来需要显式建模的流程，现在可以交给模型做一层高层抽象，但代价是可控性和确定性下降。

4. 如果要让模型真正“理解”你的业务系统，而不是只会读几段提示词，你会怎么做

不能只给一段系统提示词让它背业务规则，更稳的做法是把系统知识分层。静态知识如字段定义、权限规则、接口契约和错误语义，应该结构化存储；动态知识如用户状态、任务进度、当前环境和最近工具返回，应该作为会话状态显式注入；跨轮可复用事实如用户偏好、历史结论、常见模式，则进入长期记忆或知识库。模型真正“理解”业务，不是因为你写了一大段 prompt，而是因为你把系统约束、状态和证据组织成了它可消费的输入。

5. 你在开发过程中怎么用 AI Coding，怎样避免它把系统结构带偏

AI Coding 最适合做样板代码、接口草稿、单元测试骨架、迁移重构和阅读陌生仓库时的辅助解释，但不适合替代架构设计。避免被带偏的关键是先有人类定义清楚模块边界、数据流、异常语义和验收标准，再让 AI 去补局部实现。如果一开始就把“系统应该长什么样”也交给 AI，它很容易生成看起来完整、实际上边界混乱的代码。对于复杂 Agent 项目，AI Coding 更像加速器，不是总设计师。

6. 除了写代码，AI 在测试验证阶段能帮上什么，哪些地方不能盲信它

AI 在测试阶段最有价值的地方是生成边界用例、补齐异常路径、根据接口文档自动构造 mock 数据、从日志中聚类失败模式，以及对比多版本输出差异。它还能用于回归测试脚本生成和接口契约检查。但不能盲信它替你判断“业务逻辑是否正确”，因为它很容易生成形式上合理、业务上错误的断言。尤其在 Agent 系统里，测试不只是看最终字符串，还要验证工具调用顺序、参数完整性、状态迁移和异常恢复链路。

def check_tool_call(call):
    required = {"tool", "args", "trace_id"}
    return required.issubset(set(call.keys()))

sample = {"tool": "search_docs", "args": {"q": "合规条款"}, "trace_id": "t_001"}
print(check_tool_call(sample))

7. 检索场景中的幻觉为什么比普通聊天更危险，应该优先从哪几层去压

检索场景里的幻觉最危险，是因为它经常会披着“有依据”的外衣。模型不是完全凭空编，而是对召回证据做错误拼接、越界外推或者把旧版本内容当新规则回答。压幻觉不能只靠生成阶段说一句“请基于资料回答”，更有效的是三层一起做：检索层控制召回质量和版本一致性，编排层控制引用片段和任务约束，生成层控制答案必须绑定证据和不可超出上下文。真正线上有效的办法通常是“少给无关证据 + 强制引用 + 冲突检测”。

8. 同名文档有多个版本、甚至新旧规则互相冲突时，召回和生成应该怎么设计

这种问题不能只靠 top-k 召回解决，必须显式引入版本维度。比较稳的做法是文档入库时就带上生效时间、失效时间、版本号、组织域和权限域；检索时先按版本和时效过滤，再做语义召回；生成时若发现同一主题下有冲突内容，应该优先输出当前有效版本，并把旧版本作为对比说明而不是混进主结论。否则模型很容易把两个版本拼成一个看似合理的新答案，最难排查。

9. 如果让系统具备自迭代能力，你会把“学什么”和“怎么学”拆成哪两部分

自迭代不是让模型随便从用户对话里学东西，而是先定义可学习对象，再定义更新机制。可学习对象通常包括检索 query 重写模式、工具选择策略、参数补全模式、失败恢复路径和用户偏好，而不是直接更新主模型参数。更新机制则要区分在线轻量更新和离线验证更新：在线可以做规则统计、索引增强、记忆更新和 rerank 策略修正；离线再决定是否进入提示词更新、评测集扩充或微调流程。没有边界的自学习最后通常会变成自污染。

10. 设计一个行程规划 Agent，最关键的不是“会规划”，而是哪几个不可省的模块

行程规划这类 Agent 必须同时处理硬约束、软偏好和外部变化。不可省的模块至少包括约束解析、候选方案召回、冲突消解、成本估计、日程编排、工具调用和异常重规划。比如用户说“周五晚上到，周日中午前回，预算 3000 内，不想太赶，还要带小孩”，这里时间、预算、强偏好、弱偏好和隐藏约束全都要进状态。真正难的是当机票价格、天气、景点营业时间和用户临时改需求同时变化时，系统还能保持全局一致，而不是每次只局部修一块。

11. 这种 Agent 的扩展能力应该预留在什么地方，才不会后面一加功能就重构

扩展能力不应该寄希望于“prompt 写得足够抽象”，而要放在系统结构上。通常要把约束求解、工具层、状态存储、评分函数和输出模板解耦。这样以后新增酒店、签证、租车、天气、路线优化这些能力时，只是在候选生成或评分层扩展，而不是把整个主流程重写。Agent 的扩展性本质上来自模块边界清晰和中间表示稳定，不来自单个模型够聪明。

12. 你怎么理解 skill，skill 和 tool、workflow 的边界分别是什么

tool 更像一个原子能力，比如查天气、订机票、读数据库；workflow 是多个步骤的编排；skill 则介于两者之间，它是一个具备明确输入输出、适用条件和执行语义的能力单元。一个 skill 可能内部会调多个 tool，但对主 Agent 来说它仍然是一个高层动作，比如“生成日报”“做发票核验”“规划周末出行”。把能力抽象成 skill 的意义在于缩小决策空间，让主 Agent 不需要直接面对所有底层接口细节。