海外博主实测：AI直改OutSystems应用，MCP协议如何落地

当自然语言成为开发指令

海外博主Alex在「Beyond the Code」频道中做了一次实测：在AI宿主（如Cloud Code、Cursor、AWS Kiro）里用一句自然语言描述需求，AI Agent就能直接在OutSystems环境内完成应用修改。这个能力的底层是OutSystems MCP（Model Context Protocol）——一个让应用与外部工具和服务交互的开放协议。

这件事的意义不在于「AI能写代码」本身，而在于它把修改、审查、发布、部署串成了一条受控的工程链路。博主在视频中反复强调：背后发生的事情远不止生成代码。

连接方式：注册服务器 + 安装技能

要把AI Agent接到OutSystems上，需要两步：在MCP宿主中注册远程OutSystems MCP服务器，并安装OutSystems技能（skill）。这个技能提供指令，帮助Agent理解可用工具的使用方式，以及何时应当请求确认。博主提到，在Cloud Code中一次插件安装即可同时完成两件事。首次调用OutSystems工具时需通过浏览器登录，之后请求会携带认证令牌，OutSystems据此识别发起请求的用户身份。

MCP（Model Context Protocol）是由Anthropic提出并开源的协议，旨在为AI模型与外部工具、数据源之间提供标准化的交互方式。它采用客户端-服务器架构：AI宿主（如Claude Code、Cursor）作为客户端，通过标准接口调用远程MCP服务器暴露的工具。每个MCP服务器可以定义一组工具（tools），并描述其输入输出 schema，AI据此决定何时调用哪个工具。这种设计让AI不必为每个外部系统编写定制集成代码，只需遵循统一协议即可扩展能力，也为权限控制和审计提供了统一入口。

四步流程：从上下文到发布

OutSystems MCP把工具分为三组：Context（上下文）、Mentor、Platform（平台）。三组工具在请求流转中扮演不同角色。

第一步：先理解应用，再动手改

Agent通过Context工具检查受影响的应用信息，包括屏幕和实体。博主特别指出，它不会下载整个应用，只收集理解本次修改所需的上下文。这为后续修改提供了一个有依据的起点。

第二步：把修改交给Mentor

拿到上下文后，Agent通过Mentor工具提交修改请求，请求中携带上一步收集的信息。Mentor在OutSystems服务器上于一个会话内编辑应用模型——关键细节是：改动留在会话中，运行中的应用不会立即改变。Agent会轮询等待Mentor处理完成，这意味着修改可以被准备和审查，之后再进入已发布应用。

在OutSystems平台中，"会话"（session）指一个隔离的编辑上下文，应用模型的改动首先被暂存在该上下文中，而非直接写入运行实例。这类似于版本控制中的工作区：开发者或AI可以在会话内反复调整、预览变更，确认无误后再提交。这种机制使得修改可以被审查和回滚，而不会影响生产环境。Mentor工具利用会话机制，让Agent的修改停留在"准备"阶段，只有显式发布操作才会触发构建和部署，从而将"编辑"与"生效"解耦。

第三步：发布前必须审查

Mentor完成后，Agent会总结改了什么。博主在此处提醒：不要把生成的摘要当作走过场。你需要确认结果是否符合原始需求、是否存在需要进一步处理的意外改动。Agent的这一轮可以结束而改动并未应用到运行中的应用——审查环节是真实存在的闸门。

第四步：发布与部署的区分

确认之后，Agent使用Mentor工具发布变更。发布（publish）会构建编辑后的应用并部署到开发阶段；而部署（deploy）是把已有修订版推广到另一阶段，不重新构建。博主强调了这个区分，并且部署操作同样等待确认。编辑、审查、发布、部署之间的分离，让每个阶段发生什么更清晰，也便于控制变更在应用生命周期中的流转时机。

租户级视野与跨工具协同

单一应用的修改之外，博主展示了另一个更有意思的能力：MCP宿主可以访问企业上下文图谱（enterprise context graph），获得超出当前打开应用的租户级上下文。比如让Agent找出哪些应用与支付系统交互，或在发布订单应用变更后、部署到另一阶段前做影响分析。分析会报告部署相关影响，但不会自动阻止部署——你仍需根据结果决定下一步。

当应用共享依赖或支撑互联业务流程时，这种视野尤其有用：一个应用内看似简单的改动，可能在其他地方产生连锁反应。

博主还提到，MCP宿主也可以连接Jira、Slack等工具。当这些连接可用时，一次请求可以组合不同系统的信息：Agent读取Jira工单、在OutSystems中实现功能、再把摘要发到Slack。发布和部署仍然需要你的确认——目标是在削减需求理解、实现与沟通之间的摩擦的同时，把重要操作留在你的控制之下。

企业上下文图谱（enterprise context graph）是一种将组织内应用、服务、数据实体及其依赖关系建模为图结构的知识库。节点代表应用、接口、数据库表等资产，边表示调用、引用或数据流向。通过查询该图谱，AI可以回答"哪些应用依赖支付服务"或"修改订单模块会影响哪些下游系统"等问题。这种全局视野弥补了单个应用上下文的局限，使影响分析成为可能，但图谱本身不强制执行策略，最终决策仍由人做出。

治理：身份、权限与确认是两回事

让AI Agent直接操作企业应用，绕不开安全与治理问题。OutSystems MCP对每个请求执行两项检查：操作以你自己的身份运行；沿用ODC Portal中相同的基于角色的权限。如果你在Portal中没有执行某操作的权限，通过MCP的等效操作同样会失败——Agent不会因为走的是AI工具就绕过权限。

博主特意区分了权限与确认：权限决定你被允许做什么；确认是Agent被期望遵循的指令——OutSystems的工具描述和技能会告诉Agent解释发布或部署等变更并等待批准。如果你希望确认不完全依赖Agent是否遵循指令，可以配置MCP宿主在执行修改租户的OutSystems工具前要求批准。两者在企业开发流程中都有意义。

基于角色的访问控制（RBAC）是OutSystems ODC Portal采用的权限模型：系统预定义角色（如开发者、运维、管理员），每个角色绑定一组操作权限，用户被分配角色后即获得相应权限。当AI Agent通过MCP发起请求时，协议会携带用户身份令牌，OutSystems据此以该用户身份执行权限检查，而非以Agent或系统身份。这意味着Agent无法越权操作，其行为完全受限于发起请求的用户所拥有的权限。这种设计确保了AI辅助操作与人工操作在治理上的一致性，避免了"AI特权"带来的安全盲区。

产出的仍是标准OutSystems应用

博主最后强调的一点：无论应用是通过MCP宿主、ODC Studio中的Mentor Studio，还是ODC Portal中的Mentor Web创建或修改，结果都是标准OutSystems应用。你可以用ODC Studio打开应用检查Mentor构建了什么，或继续手工完善。部署、监控和审计能力一视同仁。引入MCP宿主并不会产生一类生命周期不同的新应用——它只是与OutSystems开发平台交互的又一种方式。

对开发者而言，真正值得关注的不是「AI能改应用」这个事实，而是这项能力如何嵌入开发生命周期、如何与既有工具互动，以及在越来越多工程工作由AI辅助时，可见性与控制如何维持。