smart
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
# 现在怎么落地：先做 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 自动执行不可逆操作，不要用工具调用绕过原有权限系统，也不要忽略降级和人工接管路径。
|
|
|
|
如果我们把这件事放到工程管理里，可以这样落地：先选一个低风险、内部可控的场景，比如后台里的查询、草稿生成、菜单创建、报表筛选；先暴露只读或低风险工具；然后加日志、加确认、加灰度；最后再考虑是否扩展到更高风险流程。
|
|
|
|
这页的核心是帮团队把兴奋感转成工程判断：方向要跟，边界要稳。越是自动化，越不能牺牲安全和可回退性。
|
|
-->
|