先看一个具体设计
agent-native 将 UI 与 Agent 接到同一组业务动作上，项目方强调两条路径共用校验、权限与实现。这个设计的意义可能不只是少写一份代码，还包括减少同一业务通过不同入口操作时的规则分歧。
例如，在一个审批系统里，通过页面和 Agent 发起“提交申请”，都应读取同一个当前版本，检查同一组必填条件，并受同一身份权限约束。这是解释设计的假设场景，并非本站或项目方已经通过的审批系统实测。
操作之后，界面还要承接什么
当部分操作被委托，使用者仍需要知道：当前发生了什么，哪里需要自己的判断，以及结果能不能确认。
以同一个申请为例，使用者需要看见 Agent 改了哪些字段、依据是什么、哪些异常还没解决，并能修改后继续。页面与 Agent 如果使用同一个业务状态，接续就有了基础；它是否真的减少人的负担，还需要验证。
哪些情况下，这个判断不成立
规则清楚、重复性高、结果可检查的动作，适合先尝试委托。涉及模糊目标、价值取舍或频繁例外时，人可能更愿意直接操作，并借界面探索信息。
强行自动化可能增加监督和纠错。设计时需要问：委托后，人是否仍能理解任务状态、及时介入，以及恢复失败？如果不能，界面职责和 Agent 的任务范围都需要重审。
什么证据会让这个判断改变
选一组相同任务，保留相同前置数据与独立验收口径，比较三种完成方式：人工、Agent，以及 Agent 执行加人工确认。
- 记录从开始到可验收的完整时间，不只看首次输出。
- 记录人工介入次数、最终错误与失败恢复成本。
- 保留失败和未完成任务，不能把它们从分母中删除。
如果协作方式只是多了一次确认，却没有降低错误或总成本，就需要缩小 Agent 的职责，或调整人介入的位置。后续实测与修订应回到同一条判断路径中。