微软 AI Agent 工程师 - 面试题 & 面经
Q: 如何设计一个企业级 Copilot Agent？与消费者 Agent 的架构差异在哪？
💡 思考逻辑： 微软 Copilot 是旗舰产品，面试官考察你对企业级 SaaS Agent 架构的理解。
参考答案： 企业级 Copilot 特殊要求：1）数据隔离——每个企业租户的数据完全隔离，Agent 不能跨租户访问信息，需要 Tenant-Aware 的上下文管理；2）权限集成——对接企业 AD/SSO（Azure Active Directory），Agent 只能访问当前用户有权限的资源（邮件、文档、日历）；3）审计合规——所有 Agent 操作记录到企业审计日志，满足 SOC2/ISO27001 要求；4）定制化——不同企业有不同的 SOP 和业务流程，需要支持企业管理员配置 Agent 行为规则；5）混合部署——支持公有云和私有云部署，大型金融/政府客户要求数据不出境。微软 Copilot for M365 的架构是：User → Copilot Orchestrator → Microsoft Graph API（访问用户数据）+ Semantic Index（企业知识检索）+ LLM（推理生成）。
Q: Azure AI 平台上构建 Agent 服务的技术栈选型？Semantic Kernel vs LangChain 的取舍？
💡 思考逻辑： 面试官考察你对微软技术生态的熟悉程度和技术选型的理性思考。
参考答案： Azure AI Agent 技术栈：1）模型层——Azure OpenAI Service（GPT-4/o1）+ Azure AI Studio 做模型评估和微调；2）编排层——Semantic Kernel（微软自研） vs LangChain 的选择：Semantic Kernel 优势在于与 .NET/C# 生态深度集成、原生支持 Azure 服务、企业级安全特性内置；LangChain 优势是社区活跃、Python 生态丰富、插件多；选择建议：微软生态重度用户选 Semantic Kernel，Python 技术栈选 LangChain；3）数据层——Azure AI Search（向量 + 关键词混合检索） + Azure Cosmos DB（对话状态存储）；4）安全层——Azure Content Safety（内容过滤）+ Responsible AI Dashboard。实际项目中，两个框架也可以混合使用——Semantic Kernel 做主编排，LangChain 做个别工具对接。
Q: Copilot 如何在不暴露用户隐私的前提下利用企业内部数据增强回答质量？
💡 思考逻辑： 企业数据安全是 Copilot 能否被采购的决定因素，面试官考察你的安全架构设计能力。
参考答案： 数据利用与隐私保护的平衡方案：1）Grounding with Microsoft Graph——Copilot 通过 Graph API 只读取当前用户有权限的文档、邮件、会议记录，不跨用户访问；2）Semantic Index——企业文档预处理为 embedding 索引，存储在租户隔离的 Azure Search 中，检索时带上用户权限过滤；3）Zero Data Retention——对话数据不用于模型训练，微软承诺企业客户的 prompt 和 completion 不会被用来改进 OpenAI 模型；4）Content Filtering——Azure Content Safety 在输入和输出两端做敏感信息过滤（PII 检测、信用卡号等）；5）Admin Controls——企业管理员可以配置 Agent 可访问的数据范围、可执行的操作类型、敏感话题的回复策略。关键原则：数据处理在企业安全边界内完成，LLM 只看到已过滤的上下文。
Q: 如何设计 Agent 的工具描述协议？OpenAPI vs 自定义 JSON Schema 各有什么优劣？
💡 思考逻辑： 微软做平台，面试官考察你对工具协议设计的深入思考。
参考答案： 工具描述协议对比：1）OpenAPI（Swagger）——优势：行业标准，现有 API 可直接复用文档；支持复杂类型定义（嵌套对象、枚举、数组）；工具齐全（自动生成代码/文档）。劣势：冗长，token 消耗大；很多细节对 LLM 理解无用（如安全配置、服务器信息）；2）自定义 JSON Schema——优势：精简，只保留 LLM 需要的信息（函数名、参数、描述）；token 效率高；可以加入 LLM 友好的自然语言示例。劣势：缺乏标准，不同框架定义不同；需要手动维护。最佳实践：1）工具描述用 LLM 友好的自然语言（不是给开发者看的 API 文档）；2）参数描述要包含约束和示例（'日期格式：YYYY-MM-DD，如 2025-01-15'）；3）控制总 token——超过 20 个工具时按意图分组，动态加载当前相关的工具子集。
Q: 如何设计 Agent 的错误恢复和自动重试机制？工具调用失败时怎么处理？
💡 思考逻辑： 微软注重工程质量，面试官考察你对生产级容错设计的系统思考。
参考答案： 错误恢复机制设计（RARF框架）：1）Recognize（识别错误类型）——区分瞬时错误（网络超时、限流 429）和永久错误（参数错误 400、权限不足 403）；2）Adapt（自适应策略）——瞬时错误：指数退避重试（backoff 1s → 2s → 4s）；参数错误：让 Agent 重新分析用户意图，修正参数后重试；权限错误：提示用户授权或切换到有权限的替代工具；3）Route（路由替代）——主工具不可用时切换到 fallback 工具（如天气 API A 挂了换 API B），Agent 需要知道每个工具的替代方案；4）Feedback（反馈用户）——重试失败后用自然语言告知用户原因和建议操作（'天气服务暂时不可用，建议稍后再试'），而不是报技术错误。实现上在 Agent 的 tool execution layer 加入 ErrorHandler middleware，统一处理所有工具错误。关键是让错误处理成为 Agent 的能力，而非终止条件。