阅读

年初，PolarDB-X团队的盛涛涛修了一个让他印象深刻的Bug。最终只改了两行代码，但查日志、看监控、分析问题花了一整天，复现调试挤在会议间隙断断续续做了近一周，之后还要补测试用例、跟进代码审查直到合并。AI已经能帮忙写那两行代码，但真正消耗时间的是前面的工作。能不能把这些也交给Agent？

团队把开发任务分成两类：新功能和迭代优化需要开发者主导方案设计，Agent辅助编码测试；而处理告警工单、修复缺陷这类工作，问题定义相对明确，代码改动通常很小，结果可以通过测试验证。他们尝试让Agent自主完成后一类任务，开发者只负责审查交付物。

但让Agent自主完成这个闭环，首先需要确保它的输出可靠。讨论可靠性时人们往往关注编码阶段，希望用特定技能或约束保证代码正确。盛涛涛指出，在缺陷修复中，可靠复现才是最重要的一步。没有复现，很难确认分析是否正确；如果分析本身是错的，即使代码结构再完美也可能无法解决真正的问题。他们据此确立三个关键要求：事故信息必须完整、问题必须可以可靠复现、修复必须通过测试验证。

围绕这三个要求，团队做了大量工具和环境建设。在信息获取方面，他们把监控、日志、实例拓扑等常用平台功能封装成CLI工具，让Agent能自主查询结构化数据而非依赖截图。对于维护不善、没有现成Agent友好接口的平台，他们参考已有CLI的实现和认证方式，让Agent分析网页底层API请求后自行封装，大约一周内完成了常用功能的集成。

真正让团队意识到问题严重性的，是一个低概率并发Bug。这个Bug在生产环境存在很久，因为发生稀少且难以复现，始终无法定位原因。Agent收到事故信息后几分钟就产出了一份分析报告，详细描述了代码位置、执行流程和可能的失败点，看起来专业且有说服力。但团队花了大约两小时验证，发现解释站不住脚。反馈给Agent后它很快产出新分析，验证后仍然错误。来回几轮，报告堆了一摞，问题依然没有解释。

根本原因在于，Agent当时只具备静态代码分析能力，无法准备环境、设置断点、控制线程执行顺序或检查内存数据。它的解释与程序实际运行行为不匹配，无法独立完成验证。为解决这个问题，团队添加了两类工具：调试和内存分析。

调试方面，核心组件用Java编写，团队最初尝试JDK自带的JDB，但它面向人类交互设计，需要维护终端进程、通过进程间通信发送命令和读取输出，对Agent来说很笨重。他们基于Java调试接口重新实现了JDB CLI，让工具在后台保持调试会话和状态，每次前台命令执行完即可退出，下次调用继续操作同一会话。结果以结构化形式返回，Agent可以解析。关键能力是线程特定断点：只有目标线程能触发断点，命中时只挂起该线程，其他线程继续运行。配合恢复操作，可以控制相关线程按特定顺序交替执行。

内存分析方面，通过Java程序的堆内存快照（Heap Dump）可以检查相关对象的字段值、引用关系和内存使用。Heap Dump文件通常很大，团队将其放在大内存云服务器上集中加载处理，为Agent提供专门的查询接口。Agent按需查询内存数据并基于结果继续分析，不必在本地处理整个大文件。

有了工具，Agent还需要运行时环境。团队提供两种选择：PolarDB-X Zero可以在几秒内创建临时实例，适合快速复现SQL错误或异常功能等简单问题；如果需要特定历史版本、特定拓扑或复杂并发场景，则在K8s中搭建完整复现环境，匹配受影响实例的版本和拓扑。完成代码修改后，Agent还可以将修复版本部署到该环境，用同样方式检查原始问题是否已解决。

回到那个并发Bug。这次Agent可以自己尝试复现，基于实际执行结果继续分析和调试。经过几轮迭代，它找到了关键触发条件，复现了与原始问题相同的MDL锁泄漏状态。关键就是Agent用调试工具让两个线程按特定顺序交替执行，故意重现了之前很难遇到的间歇性问题。调试结果还可以与内存状态交叉验证，确认复现的确实是同一个问题。至此，根因分析和可重复的操作序列都有了，Agent的分析有了实际执行的证据支撑。

在交付环节，团队把可靠复现的测试用例作为进入代码审查的关键门槛。Agent添加了测试并且通过，不足以说明原始问题已解决；必须先确认测试用例确实触发了该问题。同一个测试用例必须在修复前的版本上可靠复现原始问题，在修复后的版本上验证问题不再出现。只有这个前后验证完成、全量回归测试通过，代码才能进入审查。

这套工作流运行六个月后，团队通过处理上万条告警识别并记录了200多个缺陷，其中70%以上可以可靠复现，并在进入代码审查前由Agent完成修复。所有告警首先经过Agent的初步分析和处理，实现首轮100%覆盖。

盛涛涛总结了三条可迁移的工程经验：第一，让开发系统对Agent可访问，从团队常用系统开始，配备CLI工具或暴露API接口；第二，让开发过程可验证，提供调试工具和运行时环境，让Agent能复现问题并自行验证分析，实际执行的反馈是它发现错误、调整分析并最终完成修复的关键；第三，让任务工作流能持续运行，将工作流移到云端，使Agent不依赖开发者本地电脑。

需要指出的是，以上所有数据均为PolarDB-X团队自报，未经独立验证。该方法适用于问题定义明确、代码改动较小的缺陷修复场景，对需要开发者主导方案设计的新功能开发仍采用辅助编码模式。自建CLI工具和定制调试接口需要一定基础设施投入，迁移到其他团队的成本取决于其现有系统的可访问性。

美国科技公司谷歌于2026年11月9日宣布，其“技能”（Skills）功能正在Google Workspace Studio和核心Workspace应用中全面推出。这一功能旨在通过可复用的自定义指令，让Gemini能够应用团队的特定规则、模板和参考文件，从而帮助企业在日常工作中实现AI应用的标准化和规模化。

用户可以通过Google Workspace Studio从零开始创建技能，使用现成模板，或直接编辑Markdown原生（SKILL.md）文件。此外，用户也可以在Google Docs中起草和协作开发技能，并通过Studio分享副本，使团队成员能够在自己的工作流中启用这些技能。在Gmail、Docs、Slides、Drive和Chat等应用中，用户可以直接提示Gemini来创建、完善和测试技能，无需离开当前工作环境。

一旦启用某项技能，Gemini在这些应用中可以自动识别何时适用并执行，或者用户可以通过@提及显式调用一个或多个技能。技能还可以触发配置为“手动启动”或“按计划启动”的Workspace Studio自动化流程。例如，市场或销售团队可以利用此功能在Gmail邮件草稿、Docs提案和Slides演示文稿中保持统一的品牌语调；财务或法律专家可以依据存储在Drive中的参考指南，标准化合同或发票审查流程。

目前，技能的创建、编辑和共享仅在网页端可用，但在Gmail、Docs、Slides、Drive、Chat以及Android和iOS版Google Chat移动应用中均可调用。需要注意的是，Workspace中的技能暂不支持Google Sheets和Meet，且目前仅支持英语提示和指令。管理员可以在管理控制台中监控和审计技能活动，并根据需要禁用该功能。

亚马逊云科技（AWS）宣布扩展其安全令牌服务（Security Token Service，STS），使工作负载能够利用现有身份在不同AWS分区（如商用分区与GovCloud美国分区）之间获取临时凭证，从而访问授权资源。这一更新旨在解决企业跨分区操作时不得不保存长期有效IAM访问密钥的问题，降低密钥泄露风险及管理负担。

AWS分区是由一个或多个云端区域组成的独立环境，各分区拥有独立的身份与访问管理（IAM）系统，原本核发的凭证无法直接跨区使用。新机制通过现有的GetWebIdentityToken与AssumeRoleWithWebIdentity API实现：工作负载先从来源分区的STS获取短效JSON Web Token（JWT），再将其送至目标分区的STS交换指定IAM角色的临时凭证。目标分区STS会验证令牌并根据信任政策决定是否核发凭证，存取范围仍受IAM权限策略限制。

该功能不会默认开启，管理员需在来源账号启用对外身份联合功能，并在目标账号建立信任关系。企业可依据来源账号、IAM身份及区域设定存取条件，并通过AWS CloudTrail记录两个分区的令牌核发及凭证交换活动。目前，新功能已在所有AWS商用区域、GovCloud（US）、中国区域及德国AWS欧洲主权云区域提供，且不额外收费。

日本互联网巨头LINE雅虎（LINE Yahoo Corporation）于2026年11月10日发布了其AI智能体“Agent i”的独立iOS应用程序。此前，用户需通过LINE或Yahoo! JAPAN主应用内部访问该服务，现在则可直接从手机主屏幕一键启动。Android版本预计将在后续陆续推出。

Agent i是LINE雅虎在2026年4月整合Yahoo! JAPAN的“AI助手”和LINE的“LINE AI”后推出的服务。新版独立应用引入了“任务功能”，允许用户注册关键词以持续监控最新信息、商品降价或活动举办情况，并在任务完成时通过应用通知提醒用户。此外，应用还支持通过主屏幕小部件快速启动新聊天、图像输入和语音输入。

该应用的“领域智能体”数量已扩展至累计40个（含测试版），其中包括9月24日上线的“推活”（Oshikatsu，即粉丝应援活动）智能体，专门整理用户喜爱艺人或角色的最新新闻、活动、票务及周边商品信息。

用户可使用LINE账号或Yahoo! JAPAN ID登录，部分功能在未登录状态下也可使用，但自由文本输入需要登录。据媒体报道，Agent i底层使用了Gemini Enterprise Agent Platform（原Vertex AI）或OpenAI的API。该应用在App Store上的年龄分级为13+，官方建议13岁以下用户避免使用。

美国德克萨斯州候任州长Gina Hinojosa在接受CNN采访时向人工智能公司发出警告，称该州数据中心的“无序扩张”（free-for-all）时代已经结束。Hinojosa指出，目前数据中心主要建在缺乏监管保护的农村地区，导致“德州人正在被利用”。

她承诺将引入新法律以扭转这一局面，并呼吁在保护措施到位之前，“停止我们在数据中心方面所做的一切”。Hinojosa强调，社区必须拥有决定数据中心是否以及如何进入其所在地的权利。“我不讨厌数据中心。我讨厌他们利用德州的方式，这在我担任州长后将停止。”

德克萨斯州长期以来是美国对数据中心最友好的地区之一，但近期民调显示75%的受访者反对在其居住地附近建设数据中心。随着中期选举中民主党取得优势，包括Hinojosa在内的多位当选官员均表达了对数据中心扩张的反对立场。

这一政策转向可能对Anthropic等依赖复杂供应链的大型AI公司的未来计划产生影响。这些公司在其文件中曾警告，基础设施建设的任何延误或失败都可能对其产生重大影响。

欧洲初创企业的资金劣势最直观的呈现方式是融资规模的悬殊对比：Mistral的35亿美元D轮融资是欧洲有史以来最大的风险投资轮次，而OpenAI在2026年3月获得了1220亿美元融资，Anthropic在2026年5月获得了650亿美元，xAI在2026年第一季度获得了200亿美元。把Mistral的35亿美元放进美国最大的融资轮次列表中，只能排到第19位。投资博主Joachim Klement用这组数字引出问题，但随后引用经合组织的一项新研究将对比推得更精确。

经合组织的研究覆盖2000至2025年间在欧盟和美国创立的初创企业，将成功规模化的企业分为两类：最终估值超过110亿美元的rising superstars（崛起超级明星），以及以5000万美元领投为标准的growth-oriented companies（成长导向型企业）。研究的核心发现是，成长导向型企业在欧美两地的融资增速大致相同——这意味着欧洲并非缺乏对中等规模增长企业的资本供给。真正的分化发生在超级独角兽阶段：美国企业创立五到六年后，开始吸引远超欧洲同行的资本。

经合组织还从时间维度提供了另一组数据：从首次专利申请到获得足够资金实现规模化，约40%的欧盟初创企业花了七年以上，平均比美国同行多花1.5年。Klement将这两组发现并列呈现，说明欧洲初创企业面临的不仅是顶端资本吸引力的差距，还有整个规模化过程的起步延迟。经合组织原始报告未能独立核验，上述数据均为Klement对该研究的转述。

对投资者而言，这一发现的实际意义在于改变诊断的精度。如果认为欧洲的问题是普遍性的资本短缺，那么任何早期基金或成长基金都面临同样的困境。但如果问题集中在超级独角兽阶段，那么需要关注的变量就不同：不是欧洲有没有创业资本，而是欧洲有没有足够规模的后续轮次机构和深度退出市场来承接从优秀走向卓越的企业。Klement在文末预告周四将讨论另一项研究，指出另一个阻止欧洲初创企业规模化的关键因素，但未在本篇中展开。

安全研究公司ControlPlane的研究员Chris Nesbitt-Smith利用Anthropic的Claude Opus和Sonnet AI模型，扫描了英国政府多个部门的公开代码库，发现了超过100个严重安全漏洞。这些漏洞导致敏感数据面临风险，主要源于糟糕的网络卫生状况而非高深黑客技术。Nesbitt-Smith指出，他使用的是消费级模型并在笔记本电脑上运行，许多问题本可通过常规IT健康检查发现。

其中最严重的案例涉及负责英格兰土地使用事务的规划监察局（Planning Inspectorate）。该机构在GitHub公共仓库中意外提交并未能完全移除登录凭证，这些凭证提供了对Microsoft Entra ID的“上帝级”读写权限，可访问所有SharePoint站点、私人OneDrive账户及HR记录。虽然该机构表示在收到报告后20分钟内修复了漏洞且未发生数据泄露，但这一事件凸显了公共部门在维护其技术资产时的疏忽。

此次审计覆盖了33个组织的349个公共部门代码库，其中约三分之二存在漏洞。受影响机构包括教育部（涉及学校采购服务、教师申请系统及培训提供者注册表）和苏格兰政府开放数据门户。尽管英国政府过去十年默认公开使用公共资金生产的代码以提高透明度和复用效率，但资金紧缩导致维护不足。

随着AI加速漏洞发现，关于公共部门是否应停止开源源代码的争论日益激烈。据报道，英国国家医疗服务体系（NHS）已在5月下令技术团队转向非开源代码。然而，Nesbitt-Smith警告称，如果不先解决底层问题就关闭代码库是“最坏的情况”，因为攻击者可能已经镜像了这些仓库，而关闭反而可能引起更多关注。

AI笔记工具Otter AI于2026年11月9日宣布扩大其多语言能力，包括一项新的转录功能，能够跟随同一会议中说话者在不同语言之间的切换。此次更新是该公司迄今为止最大规模的语言扩展，新增了27种语言的支持。一旦全面部署完成，Otter将总共支持31种语言，使平台对国际团队更加易于使用。

即将推出的功能将自动检测语言变化并继续转录，无需用户调整设置。例如，通话可以从英语切换到韩语再到葡萄牙语，而Otter会全程跟随对话。这一更新旨在解决全球团队面临的常见挑战，即语言差异可能使会议和协作变得更加困难。

目前已有13种新语言可用，包括简体中文、韩语、德语、意大利语、粤语、葡萄牙语、俄语、印度尼西亚语、马来语、荷兰语、土耳其语、越南语和波兰语。其余14种语言（如瑞典语、丹麦语、阿拉伯语、印地语等）将在不久后上线。这些新添加的语言运行在Otter自己的语音模型上，公司表示它们是使用公开数据集训练的，并与母语志愿者合作审查了转录文本以检查准确性。

此次公告发布之际，Otter正继续从转录领域扩展到其它工作场所AI工具。此前，该公司获得了General Catalyst的3.2亿美元融资，并推出了利用会议历史和连接应用帮助用户准备即将到来的通话的“Work Mode”，以及在会议期间提供实时指导的“Live Assist”功能。

美国网络安全与基础设施安全局（CISA）于11月9日发布声明，宣布已将四个存在积极利用证据的漏洞加入其“已知被利用漏洞目录”（Known Exploited Vulnerabilities, KEV）。这些漏洞涉及多个关键基础设施领域，包括用于GPU资源管理和AI模型服务部署的GPUStack（CVE-2026-102895）、软件定义电信交换平台FreeSWITCH（CVE-2026-116779）、远程安全连接库OpenSSH（CVE-2026-123158，即“SSHole”）以及IBM企业文件传输与协作平台Aspera Faspex（CVE-2026-123218）。

根据CISA的要求，所有联邦机构必须在11月12日之前完成对这些漏洞的修补工作。这一紧迫的时间表反映了此类漏洞一旦被恶意利用，可能对联邦政府信息系统造成重大风险。在这四个漏洞中，OpenSSH的“SSHole”身份验证绕过漏洞影响范围最广，而其余三个漏洞的通用漏洞评分系统（CVSS）严重程度均达到9.8分，属于最高级别的严重漏洞。

独立技术分析师Richard Windsor在其最新分析中提出了一个判断：围绕Nvidia CEO黄仁勋的争议已经使主张放宽对华AI芯片出口的一方在政治上失去了立足之地，无论其经济论据本身是否成立。Windsor指出，黄仁勋一直是最直言不讳的倡导者之一，这不难理解——中国超过80%的民众对AI持正面看法，电力资源充沛，而Nvidia可以说拥有全球最好的AI训练与推理系统，其可触达市场正因无法进入中国而受到压缩。

但Windsor认为，问题的关键不在于经济逻辑是否成立，而在于谁来讲述这个逻辑。他写道，黄仁勋对Nvidia股东的信托责任要求他游说美国政府放宽限制，这本身无可指摘。然而近期曝光的事件——涉及黄仁勋配偶可能与中国国家存在关联的指控——已经使这一游说路径的政治可信度遭到根本性破坏。Windsor用了一个条件句来表述：

如果黄仁勋女士确实是中国国家的代理人，那么可以轻易论证她的角色就是影响黄仁勋在华盛顿推动放松出口限制——而这正是他所做的。

Windsor进一步分析了中国方面的策略逻辑。他指出，任何与中国进行过贸易谈判的人都会告诉你，中国首先要求的是先进Nvidia芯片，而非美国允许出口的降规格版本。将这一谈判行为与黄仁勋的游说活动放在一起解读，可以得出一个推论：中国想要的是先进芯片，而不是美国愿意给出的二流替代品。这一策略的合理性在于，先进芯片将使中国在AI领域更具竞争力，同时为国产芯片争取追赶时间，最终将Nvidia和其他外国厂商从系统中移除。

Windsor的结论是，这一事件的实际后果将是美国对中国的芯片进口限制进一步收紧，中国在AI硅片上的劣势将持续存在。这意味着中国将更加依赖从邻国数据中心进口使用西方芯片的算力服务。Windsor指出，这一替代方案虽然可行，但存在一个结构性脆弱点：美国可以立法规定，使用美国芯片的数据中心不得为最终在中国大陆使用的负载提供服务。这一选项目前尚未被启用，但只要依赖关系存在，它就始终是一个可用的政策工具。Windsor认为，这正是美国与西方在AI领域仍然保持较大优势的原因，且短期内不会改变。

需要说明的是，Windsor的核心论据建立在未经证实的指控之上，他本人也使用了条件性表述。他的分析价值在于提供了一个具体的机制解释——个人信誉如何使一个本可独立成立的政策论据在政治环境中变得不可用——而非对指控本身的独立证实。即便没有这一信誉危机，主张放松出口的经济逻辑仍然可以由其他倡导者重新提出；Windsor的判断是，在当前政治氛围下，这一路径已经难以走通。

Anthropic 在 Claude Fable 5.2 的提示工程文档中记录了一项对编码代理行为有直接影响的发现：模型如何处理已有代码结构，高度取决于提示中关于代码归属的表述。在小型编码任务的测试中，当提示没有提及归属或将代码库描述为他人所有时，模型倾向于在现有结构上继续添加，即使这意味着重复已有代码。

改变这一行为的具体方法是在系统提示中加入一句归属声明：「This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.」Anthropic 的测试数据显示，包含这句话时模型在约一半的尝试中合并了重复代码，而缺少这句话时该比例不到一成。这一效果在长系统提示中同样成立，且所请求的功能在两种情况下几乎都能正常工作。

不过这一策略伴随明确的代价。同一测试中，加入归属声明的模型使用了约 1.5 倍的输出 token，并做出了若干未被请求的修改——多为新增测试和文档。更值得注意的是，除 bug 修复外，模型在约六到十分之一的尝试中改变了现有功能的行为，且在更高 effort 级别下该比例更大。其最终摘要通常列出较大改动但遗漏小改动，因此 Anthropic 建议审查 diff 而非仅看摘要。此外，即使提示中另有「No drive-by refactors, renames or cleanups」的范围限制规则，模型仍在约三分之一的尝试中执行了合并。

Anthropic 的文档同时给出了适用边界：当用户拥有代码且希望改动尽可能少时，应省略归属声明。测试范围限于小型编码任务，结论能否外推到大型代码库尚不确定。Simon Willison 在 2026 年 11 月 10 日引用了这一发现，将其作为 Claude Fable 5.2 提示策略中一个具体且可操作的案例。

2026年11月9日，阿里巴巴旗下千问办公正式发布2.0版本，推出了业内首个面向团队协作的“Team Agent”（团队智能体）。这一更新旨在解决当前企业级AI应用中一个普遍存在的痛点：尽管个人使用AI代理能显著提升单任务效率（如写报告、做表格），但整个组织的协作流程往往并未因此加速，导致个体效率的提升无法转化为组织整体产出的倍增。

千问办公2.0的核心突破在于打通了沟通场与生产场。以往，企业尝试将AI引入工作流主要有两条路径：一是给独立的AI产品增加群聊功能，但这要求员工迁移完整的工作上下文，难度极大；二是在现有的即时通讯（IM）工具中嵌入AI，但IM终究是沟通场所，缺乏深度内容生产能力，用户仍需切换软件处理复杂任务，导致上下文断裂。

新版本选择将两者结合。它允许团队关联原有的钉钉群和项目资料，使Agent能够实时理解业务背景。同时，它提供了完整的文档共创、表格处理和任务执行能力。例如，在销售、设计和运营协同的场景中，Agent可以捕捉群内的讨论共识，自动整理进度并创建待办事项，不同岗位的成员可以在同一上下文中继续各自的生产工作，无需反复同步信息。

极客公园的实测显示，该功能在处理分散信息的场景下表现突出。在月底发票整理场景中，Agent可以直接从关联的钉钉群中提取文件并进行分类汇总，减少了人工搬运和整理的时间。在银泰百货的案例中，覆盖62家门店的直播卡券业务通过关联60多个门店群，实现了进度的自动同步和状态追踪，负责人无需逐群询问即可掌握整体情况。

千问办公之所以能实现这种深度集成，得益于阿里生态的业务基因。钉钉服务超2000万企业组织，沉淀了大量消息、文档和审批数据，为Agent提供了丰富的生产级上下文。此外，阿里云和电商平台本身也是典型的2B服务场景，内部数万员工的日常协作需求推动了产品的快速迭代。

尽管目前的效果主要基于厂商演示和早期客户反馈，但千问办公2.0标志着企业AI从“个人助手”向“组织协作者”的角色转变。未来，其计划进一步接入更多第三方SaaS应用，并扩展至飞书、企微等其他IM平台，以降低企业采用新AI能力的门槛。