# 现在怎么落地：先做 Agent 友好，不赌单一 API

<div class="grid grid-cols-2 gap-8 mt-8">

<div class="card-green">
<div class="font-semibold mb-3">现在就值得做</div>
<div class="space-y-2 text-sm">

- 补语义化 HTML 与可访问性
- 梳理核心业务动作边界
- 把复杂流程沉淀成任务说明
- 在内部系统试验 WebMCP / SDK
- 给高风险动作加确认和审计

</div>
</div>

<div class="card-red">
<div class="font-semibold mb-3">暂时不要这样做</div>
<div class="space-y-2 text-sm">

- 把实验 API 当生产强依赖
- 假设 Safari / Firefox 已支持
- 让 Agent 自动执行不可逆操作
- 用工具调用绕过权限系统
- 忽略降级和人工接管路径

</div>
</div>

</div>

<!--
这一页讲落地策略。

因为 WebMCP 和部分内置 AI 能力仍然在实验阶段，所以我们不能把这场分享讲成“明天所有项目都要接这个 API”。这样讲既不准确，也不负责任。更稳妥的落地策略是：先做 Agent 友好，不赌单一 API。

现在就值得做的事情有几类。第一，补语义化 HTML 和可访问性，因为这本来就是现代 Web 的基本功，也能让 Agent 更容易理解页面。第二，梳理核心业务动作边界，比如创建、查询、提交、审批、导出，这些动作未来都有可能成为可调用能力。第三，把复杂流程写成任务说明或操作手册，让 Agent 知道什么顺序是安全的。第四，在内部后台、Electron 或受控环境里试验 WebMCP 或相关 SDK。第五，对高风险动作加确认、权限和审计。

同时，暂时不要做的事情也要说清楚。不要把实验 API 当成生产强依赖，不要假设 Safari、Firefox 或各种 WebView 都已经支持，不要让 Agent 自动执行不可逆操作，不要用工具调用绕过原有权限系统，也不要忽略降级和人工接管路径。

如果我们把这件事放到工程管理里，可以这样落地：先选一个低风险、内部可控的场景，比如后台里的查询、草稿生成、菜单创建、报表筛选；先暴露只读或低风险工具；然后加日志、加确认、加灰度；最后再考虑是否扩展到更高风险流程。

这页的核心是帮团队把兴奋感转成工程判断：方向要跟，边界要稳。越是自动化，越不能牺牲安全和可回退性。
-->