Agent First:App 不再是入口,而是能力载体,AI 应用新范式

Aham Survey 真正的转折，不是我给它加了 AI，而是我删掉了“新建项目”按钮。

我一开始只想解决一个很具体的问题。做 ERP、MES、WMS 调研时，现场一边聊一边记，回来还要对着录音和零散笔记重新整理。部门、问题和证据很容易散掉。

所以我做了 Aham Survey。先把项目、部门、题目和答案装进一个本地 App，让一次访谈能直接沉淀为结构化结果。

第一版很像一款正常的专业软件：顶部按部门切换，左侧是章节和问题，中间聚焦当前题目，右侧放提示和部门进度。顾问记录、现场备忘、已采纳追问，最后一起进入报告。

图 1 · Aham Survey 的聚焦式现场问答

数据保存在本机。题型、合法选项、完成进度和触发提醒由 App 判断。到这里，它已经是一把能用的现场工具。

接下来走的是一条很自然的路：既然是 AI App，就让它再聪明一点。

我做过客户文档分析、产品与工艺搜索、知识库训练、动态选项、优先级排序，也把润色和追问放进界面。每碰到一个问题，就准备再加一个模块。

图 2 · 从调研工作台走向一款“大而全”的 AI App

功能确实多了。但开发到后面，我越来越清楚：最难的部分不是调用一次模型，而是让 App 提前知道所有行业应该怎么调研。

编一套通用题库并不难。难的是面对一家具体企业，先理解它生产什么、工艺怎么走、哪些异常值得追问，再决定这次应该把时间放在哪里。

离散装配、机加工和流程生产，可以共享一些基础问题，但不会共享同一套高价值追问。题库做得太通用，现场问不深；题库继续膨胀，顾问又很难用。

图 3 · 标准结构与动态判断之间的缺口

而这些恰好是强 Agent 擅长的工作：读客户资料，搜索行业工艺，比较多个来源，再根据当前上下文生成提纲和追问。为了使用这些能力，我没有必要在每个 App 里重新做一遍搜索、文件阅读和模型编排。

于是这次重构反过来了。我移出了产品与工艺搜索、知识库训练、客户文档分析和项目级 AI，也把语音转写交给独立工具。

最后，我连“新建项目”按钮也删了。项目由 Agent 根据用户资料创建；App 只接收结构化、经过校验的结果。

图 4 · 从 App 中移出什么，又留下什么

留下来的部分反而更清楚：本地项目、标准题库、现场界面、答案校验、触发规则、变更记录、撤销和导出。App 变小了，但它对结果负责。

我给 Aham Survey 加了一个只监听本机的 MCP 服务，又写了一份 Agent Skill。

MCP 负责把项目、题目、答案和导出能力交给 Agent。Skill 负责另一件事：告诉 Agent 先读什么、哪些事实不能猜、批量回写为什么必须先预览、冲突后怎样重新确认。

图 5 · 当前 Aham Survey 首页的 MCP 控制台

现在，一段访谈材料可以先由 Agent 拆成证据，映射到 App 返回的真实题目；App 校验题型和选项，生成预览；用户确认后再提交。写入完成，结果仍回到现场界面和报告里。

目前这条链路已经覆盖项目创建、题目读取、访谈映射、预览提交、变更记录、撤销和导出。行业搜索后把自定义提纲完整写回 App，还是我准备继续补的一段。

我不是先想出一套架构，再找 Aham Survey 来证明。顺序正好相反：先做 App，给它不断加功能，撞到知识边界，再通过删减和外接，把各自的职责分开。

图 6 · 从一次 App 重构中长出来的 Agent First

这时我才意识到，App 不一定继续承担所有交互。人可以先把目标交给 Agent；Skill 提供业务方法；MCP 把动作交给 App；App 保存事实，执行确定规则，并在人真正需要时提供专业界面。

我现在更想讨论的，不是 App 会不会消失，而是下一款 App 开发时，我们会先画页面，还是先决定应该向 Agent 开放哪些可信能力。