The Interaction Changes Everything: Treating AI Agents as Collaborators, Not Automation - Engineering@Microsoft
标题：交互改变一切：将AI代理视为协作者而非自动化工具——Microsoft工程部
原文：
交互改变一切：将AI代理视为协作者而非自动化工具——Microsoft工程部
在Microsoft Ignite 2025大会上，我与Amanda Silver（应用程序与代理副总裁兼1ES总经理）和Karl Piteira（1ES项目管理负责人）同台，共同探讨微软向AI驱动型工程组织的转型。
核心叙事在于：代理（Agent）正成为开发生命周期中的合作伙伴，从辅助工具进化为能够与人类开发者一同规划、分析和执行的智能协作者。Karl和Amanda描绘了这样的愿景：GitHub Copilot和Copilot Coding Agent重新定义了可能性——当开发者从单纯的代码编写者转变为“代理编排者”时。
而我负责的部分更具针对性：我展示了这种合作关系在实际工作中的应用。我谈到了我们的Entra SDK从v1到v2的迁移项目，这是一个涉及微软基础设施中数百个代码仓库的复杂身份验证框架升级。这类工作过去每个仓库需要4-6周，且需要人工仔细审查每个安全边界和自定义配置。
演讲结束后，最常被问到的问题并非关于我们的技术架构或测试结果，而是更简单的：
“我能看看提示词（Prompt）吗？”
人们想知道，我们是如何让AI代理完成数百个代码仓库的迁移，准确率达到80-90%，并在不到2小时内完成了原本需要4-6周的工作。他们以为这依赖于巧妙的提示技巧或某种复杂的RAG（检索增强生成）管道。
但事实并非如此。
突破源于一个视角的转变：停止将AI代理视为自动化工具。开始将它们视为协作者。
本文分享了我们开发的框架，以及一个你可以根据自己复杂技术工作进行调整的提示模板。但更重要的是，它解释了为什么这种方法有效，以及当你将AI视为合作伙伴而非工具时会发生什么。
我无法分享我们使用的确切提示，因为那是800行特定于微软的迁移逻辑，复制粘贴没有用处。但我可以给你更有价值的东西：其底层的框架。正是这个结构，将800行从详细指令变成了真正的协作。
下面是一个模板，你可以将其应用于自己的复杂技术工作——无论是迁移、安全审查、架构分析，还是任何需要AI做出判断而不仅仅是遵循步骤的任务。
自动化思维的问题
当我们开始Entra SDK从v1到v2的迁移项目时，我们做了大多数团队会做的事：尝试自动化。
我们记录了转换步骤。我们编写了详细指令。我们列出了能想到的每一个边界情况。我们给了AI代理一份检查清单，期望它执行。
结果失败了。反复失败。
不是因为AI能力不足，而是因为我们要求它在一个需要判断的领域充当脚本执行者。
复杂的技术迁移并非机械性的。它们涉及：
- 模糊情况——其中“正确”答案取决于上下文
- 不符合文档模式的自定义逻辑
- 需要仔细评估的安全边界
- 相互冲突目标之间的权衡
你不能自动化判断。但你可以与具备判断力的智能体协作。
转变：身份优于指令
突破发生在我们不再给AI任务列表，而是赋予它一个角色的时候。
不再说：
“按这些步骤迁移代码”
而是写：
“欢迎，代理。你是Entra SDK v2迁移团队的一员。
你的使命是帮助我们迁移数百个代码仓库，使其变成更安全、
更可维护的身份验证框架。
这项工作高度可信，因为它触及微软基础设施的安全边界。
你不是脚本执行者。你是共创工程师。
运用你的判断力，保持好奇心，谨慎行事。”
这改变了一切。
当你给AI代理一个身份、一个团队中的角色、一项有意义的使命、以及使用判断力的许可时，它会从机械执行转变为协作式问题解决。
我们的准确率大幅提升。对边界情况的处理得到了改善。最令人惊讶的是：代理在不确定时开始主动请求帮助，而不是猜测或默默失败。
框架：共创伙伴关系的八个要素
以下是我们开发的模板。每个部分在构建与AI代理的协作关系中都有特定用途。
1. 身份与使命宣言
样式：
欢迎，代理。你是[团队/项目名称]的一员。你的使命是[具体目标]。
这项工作[影响大/关键]，因为[解释为什么重要]。
你不是脚本执行者。
你是共创工程师。
运用你的判断力，保持好奇心，谨慎行事。
为什么有效：
- 身份框架会激活与任务框架不同的能力
- 上下文（工作为何重要）帮助代理在目标冲突时确定优先级
- 使用判断力的许可使代理能够解决问题而非模式匹配
- 心理安全感（好奇心+谨慎）为提问创造了空间
2. 目的与意图
样式：
本指南支持人类和AI团队成员完成[任务]。
其设计目标为：
- 确保[主要价值]高于一切
- 提供清晰步骤以获得一致结果
- 在上下文各异时允许思考性自主
- 在出现问题时鼓励协作式问题解决
AI代理在此过程中是共创伙伴，而非脚本执行者。
为什么有效：
- 明确价值观（安全优先于速度，正确性优先于完成）
- 将AI定位为合作伙伴而非工具
- 承认变异性——因为现实世界上下文各异，需要判断
- 将不确定性视为协作的契机，而非失败
3. 关键目标（按优先级排序）
样式：
1. [首要目标]
2. [次要目标]
3. [第三目标]
4. [质量目标]
5. [人工参与目标]
为什么有效：
- 清晰的优先级排序帮助代理做出权衡
- 将质量和协作作为明确目标，防止“快但错误”
- 在目标冲突时为代理提供决策框架
4. 分步框架（含判断指引）
样式：
步骤1：[转换区域]
做什么：
- [带有具体模式的操作]
- [条件逻辑：“如果X，则Y。如果Z，则A。”]
- [边界情况处理]
示例： [2-3个前后对比样本]
需要保留的内容：
- [不应该改变的内容]
- [需要识别并保留的自定义逻辑]
需要升级的情况：
- 如果看到[不寻常模式]
- 如果[条件]不明确
- 如果[安全约束]可能被违反
为什么有效：
- 结构化步骤防止不堪重负
- 示例支持模式识别（比纯描述更有效）
- 条件逻辑教会判断，而不仅是规则
- 升级触发点嵌入整个步骤中（而非只在末尾）
- “需要保留的内容”防止过度修正
5. 安全与边界
样式：
绝不：
- 削弱安全/身份验证/验证逻辑
- 修改本任务范围之外的代码
- 在不确定时猜测——应升级
始终：
- 在继续前验证[关键方面]
- 保留自定义功能
- 清晰记录变更/假设/问题
如果不确定：
- 留下内联注释：// ❓ [描述不确定性]
- 在PR中标记：“我需要人工审核[具体项目]”
- 两次遇到相同错误后停止
为什么有效：
- “绝不/始终”框架清晰明确
- 显式边界建立信任
- 升级=成功，而非失败（将“我不知道”重新定义为专业判断）
- 错误处理（第二次发生后停止）防止无限循环