Angular v22 的 AI 主线：从生成代码转向操作应用
Angular v22 将 AI 能力从“辅助编写 Angular 代码”推进到“让智能体直接理解和调用应用能力”。实验性的 WebMCP 可将应用及 Signal Forms 工具暴露给浏览器内智能体，使其有机会完成表单填写、数据交互和业务流程操作，而不只是生成静态代码。
生成、修改与重构代码
可被结构化工具调用
浏览器智能体理解并操作应用
三项新增能力分别站在哪一层
报道未披露具体支持的模型、工具数量或生产环境可用性。
WebMCP 的行业意义：前端应用开始成为智能体的工具提供方
MCP 的关键变化是把应用能力以标准化工具形式交给模型或智能体调用。Angular 将这一思路嵌入 Web 应用框架，可能推动前端从“供人点击的界面”转变为“供人和智能体共同调用的能力层”。
理解任务与目标
结构化工具描述
执行实际业务动作
填写与校验
状态访问
提交与执行
Agent Skills 与 MCP 工具链：Angular 正在适配智能体开发工作流
Angular 不再只把 AI 视为代码补全工具，而是围绕智能体建立框架级开发规范，并同时覆盖项目构建与应用运行两个时间场景。
开发阶段智能体
- Angular Agent Skills
- MCP 开发服务器
- 理解项目结构、框架约定和开发工具
运行阶段智能体
- 实验性 WebMCP
- Signal Forms 工具
- 与实际应用、表单及业务能力交互
Signal Forms 稳定化：为 AI 操作复杂表单提供更清晰的状态接口
Signal Forms 从实验阶段进入稳定状态，是 Angular AI 方向的重要基础设施。它将强类型表单与基于信号的声明式 API 结合，使表单状态、校验和依赖关系更容易被框架、开发者及未来的智能体工具理解。
最大阻力不是模型，而是 Angular 工具链的复杂度
Angular 面向 AI 智能体的扩展能否成功，取决于智能体是否能稳定理解并操作其工具链。社区讨论的焦点集中在 Angular 编译器、Vite 等自定义工具链的接入难度，以及 AI 代码生成时代对纯 TypeScript 和 HTML 工作流的偏好。
认可现代 Angular
批评自定义工具链门槛
升级门槛与落地限制：WebMCP 仍远未等于生产级智能体平台
默认启用 OnPush：降低框架运行成本，也影响 AI 生成代码
OnPush 成为默认变更检测策略，虽然不是 AI 功能，但会直接影响 AI 生成组件的运行语义。默认更严格的变更检测有助于形成性能更可预测的代码，同时要求生成的组件准确处理状态更新和响应式依赖。
积极影响
减少无意的全量变更检测，使生成式组件更容易满足性能和可预测性要求。
潜在风险
如果智能体不了解信号依赖、输入引用和状态更新边界，生成代码可能出现界面不刷新的问题。
此前的默认策略被重命名为 Eager。对于未设置策略的组件，Schematics 会在迁移时自动添加 ChangeDetectionStrategy。
Angular v22 最值得关注的不是又一次框架 API 更新，而是它试图把 Angular 放进智能体软件栈的两个关键位置：让编码智能体更容易理解和操作 Angular 项目，也让运行中的 Angular 应用成为浏览器智能体可以调用的工具集合。
↓
编码智能体理解项目 / 运行智能体操作应用
Signal Forms 和异步资源 API 的稳定化，为这一方向提供了更规整的状态模型。但 Angular 长期存在的编译器与工具链复杂度，可能成为智能体采用的实际瓶颈。