微软研究院发布了 OptiMind,这是一个基于 AI 的系统,能够将复杂决策问题的自然语言描述转换为优化求解器可执行的数学公式。它解决了运筹学中长期存在的一个瓶颈问题:将业务意图转换为混合整数线性规划通常需要专业建模人员和数天的工作。

OptiMind 是什么以及它输出什么?

OptiMind-SFT 是 gpt-oss transformer 系列中的一个专业化 200 亿参数专家混合模型。每个 token 约激活 36 亿参数,因此推理成本更接近中型模型,同时保持较高的容量。上下文长度为 128,000 tokens,这允许在单个请求中处理长规范和多步推理轨迹。

agent_framework 是微软推出的 Python 库,专门用于构建 AI 代理应用程序。我在研究这个框架时发现,它为聊天代理、工作流、工具调用和中间件提供了非常优雅的抽象。核心类包括实现 AgentProtocol 协议的代理、用于在工作流中运行代理的执行器、用于聊天输入/输出的消息,以及用于定义工作流拓扑的构建器。例如,AgentProtocol 是一个结构化接口,任何代理都必须遵循它(比如 ChatAgent 就实现了这个接口)。

在研究 AI Agent 的过程中,我发现了一个有趣的现象:虽然质量至关重要,但成本和执行时间(推理时间)往往成为 Agent 管道中最大的争议点。

像 GPT-5.2 或 Gemini 3 Pro 这样的"推理"大语言模型确实可以提高质量。然而,我注意到它们往往存在生成时间长和 token 使用量增加的问题,从而推高了成本和延迟。当 Agent 需要在每个任务中做出大量决策时,这种权衡就会成为一个重大瓶颈。

Microsoft Foundry(2025 年 11 月之前称为 Azure AI Foundry)在使用服务时提供两种身份验证方式,包括 LLM 推理:基于密钥的身份验证和 Entra ID 身份验证。虽然基于密钥的身份验证更容易使用,但我想在这里分享使用 Entra ID 身份验证的优势,以及如何开始使用它的分步说明!

Entra ID 身份验证的优势

基于密钥的身份验证快速简单……只需从 Foundry 门户获取 API 密钥,将其作为 header 插入 api-key 名称下,就可以开始使用了!然而,由于其简单性,基于密钥的身份验证也存在一些限制。主要限制之一是安全性。虽然基于密钥的身份验证很简单,但它是"全有或全无"的访问方式——任何拥有该密钥的人都可以执行资源允许的任何操作。

2026 年是 agentic AI（具备“规划 + 工具调用 + 迭代执行”的自主/半自主智能体）从原型走向生产的关键拐点：不再只是“把 agent 跑起来”，而是开始进入架构化、标准化、可治理、可算账的阶段。

基础概念：先把“造车零件”补齐

在进入 7 个趋势之前，一组“底座能力”的延伸阅读：

• Agent 设计模式（例如 ReAct、Reflection、Tool Use、Planning、多智能体协作、串行工作流、Human-in-the-Loop）：https://machinelearningmastery.com/7-must-know-agentic-ai-design-patterns/
• 让 agent 有“长期记忆”的三种形态（episodic / semantic / procedural）：https://machinelearningmastery.com/beyond-short-term-memory-the-3-types-of-long-term-memory-ai-agents-need/
• 用小模型（SLM）替代超大模型，做高频/低风险任务以降低成本：https://machinelearningmastery.com/small-language-models-are-the-future-of-agentic-ai/
• 选型与实践路线：https://machinelearningmastery.com/top-5-agentic-ai-llm-models/、https://machinelearningmastery.com/the-machine-learning-practitioners-guide-to-agentic-ai-systems/、https://machinelearningmastery.com/the-roadmap-for-mastering-agentic-ai-in-2026/

如果团队还在“单一大模型 + 一把梭”的阶段，建议先把这些概念统一语言，再谈规模化。

封面图来源：Addy Osmani / Substack（见原文页面）。

原文链接：https://addyo.substack.com/p/code-review-in-the-age-of-ai?WT.mc_id=AI-MVP-5003172

AI 让写代码更快，但并没有“杀死”代码审查；相反，它把“举证责任”变得更明确了：你可以让 AI 帮你更快地产出改动，但你仍然需要用证据证明它真的能跑、真的符合预期。

作者 Addy Osmani 在文中给出的核心观点很直白：如果一个 Pull Request 里没有“它能工作”的证据（手动验证步骤、日志/截图、自动化测试结果等），那并不是在更快地交付，只是在把风险和返工推给下游。

在我们的一生中，我们不断评估周围人的技能和能力。我应该雇用谁？谁应该在团队中比赛？我可以向谁寻求帮助？我如何最好地教导这个人？综合我们对某人的所有了解，并弄清楚他们能做什么和不能做什么，这对我们大多数人来说都是很自然的。但是我们如何使用基于模型的机器学习来自动完成这项工作呢？

在本章中，我们将开发我们的第一个针对真实世界数据的模型。我们将解决评估需要特定技能的工作候选人的问题。其想法是候选人将参加多项选择测试，我们将使用基于模型的机器学习来确定每个候选人具有哪些技能（以及具有什么概率），这些信息基于他们在测试中的答案。然后，我们可以使用这些信息来执行诸如选择很可能具有一组必要技能的候选人的初选名单等任务。

贝叶斯博士掏出她可靠的放大镜，继续在犯罪现场调查。她在布莱克先生尸体附近的地板上，发现了一根落在血泊上的头发。“啊哈！”贝叶斯博士惊呼，“这根头发一定属于谋杀发生时在房间里的人！”她仔细观察这根头发，发现它既不是奥本小姐那一头鲜艳红发的色泽，也不是受害者乌黑的头发，而是格雷少校那种沉稳的银灰色！

原文链接：https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/from-zero-to-hero-building-a-production-ready-sip-gateway-for-azure-voice-live/4473405?WT.mc_id=AI-MVP-5003172

题图来源：Microsoft Tech Community / Microsoft Foundry Blog

引言

语音技术正在重塑人和机器的交互方式，让与 AI 的对话比以往更自然。随着 Voice Live API 的 public beta 发布，开发者拥有了构建低延迟、多模态语音体验的工具，在应用中可以做出很多新玩法。

过去，想做一个语音机器人，往往需要把多个模型“串起来”：比如用 ASR（自动语音识别）模型（像 Whisper）做转写、再用文本模型做推理、最后用 TTS（文本转语音）模型生成语音输出。这条链路通常会带来明显延迟，并且在情感表达等细节上会有损失。

Web AI Agent 代表了 AI 在真实系统落地方式的一次大转向：它不再只是“生成文本”，而是会观察实时网页、做决策、并执行真实动作（点击按钮、提交表单、在应用中导航）。能力的跃迁带来巨大价值，但也带来更本质的风险：它更暴露、更容易被利用，如果系统设计草率，后果会比纯文本聊天严重得多。

下面的观点基于近期的安全分析：Web AI Agent 的关键问题不是“模型不够聪明”，而是“系统边界不够硬”。理解脆弱性从何而来、会以什么形态出现、以及应该怎样修复，对于任何在做 AI 产品/平台/研究系统的人都很关键。