过去一段时间，我使用 AI 的方式一直在变。
最早是 ChatGPT。那时它更像一个很聪明、随时在线的聊天机器人：陪我讨论问题，帮我修改文字，解释陌生概念。它比搜索引擎更像一个“可以对话的知识入口”，但基本模式仍然是我提问、它回答，然后这一轮结束。
后来我开始更频繁地把豆包当搜索引擎。面对一个需要快速扫清背景、比较多种说法或理解陌生领域的问题，搜索更适合先把世界铺开。再后来是 Claude Chat，它开始帮我处理长材料、整理思路，完成一些简单但完整的工作。
复杂工作很快暴露出聊天窗口的边界。一个项目不只是一次问答。它有历史决策、真实文件、多个版本和需要反复验证的产物，也有不能只靠“看起来不错”来判断的结果。于是我开始使用 Cowork；当工作里出现脚本、Skill、文件处理和代码修改时，我转向 Claude Code。因为额度和可用性，我又开始更深入地使用 Codex。
这不是一条经过设计的“最佳工具栈升级路线”，而是一种自然迁移：每一个新工具都把我能交给 AI 的事情向前推进了一点，也都在下一类问题面前露出了新的边界。
聊天与讨论
→ 搜索与研究
→ 长材料与简单交付
→ 有文件、有上下文的复杂协作
→ 脚本、Skill 与代码
→ 多个项目、多个 Agent、多个设备上的持续工作走到最后，我发现自己不缺一个更会聊天的模型，也不只缺一个更会写代码的 Coding Agent。
我缺的是一个能把这些能力、我的真实数据和我的真实行动连接起来的系统。
AI 已经进入许多单点工作流，但还没有成为我的生活基础设施
过去几个月，我做了不少 AI 项目。
演出雷达让我第一次把不稳定的信息源、LLM 结构化、服务端、iOS 客户端和日常摘要接成一条链；个人主页让我开始持续公开自己的思考和实践；知识库、Agent Sync、脚本和 Skill 让我逐渐理解，上下文、规则与跨机器连续性不是附属品；Agent-Ready Benchmark 又逼着我面对一个更硬的问题：Agent 说自己完成了，和它真的完成了，可能是两件事。
这些项目不是一串互相独立的作品，更像不断累积的中间答案。
AI 已经可以帮我写文章、做研究、整理知识库、生成脚本、修改代码、检查项目状态，甚至操作一部分界面。但能力越多，我越清楚地意识到：我自己仍然是那个负责把它们串起来的人。
我要在家里的 Mac mini、公司的 MacBook、iPhone 和家里的 Windows PC 之间切换。今天，这种连续性主要依靠两层工具：iCloud 云盘同步素材、知识库和需要随设备移动的文件；GitHub 同步代码、项目状态、决策与可追溯的版本历史。它们已经是我跨设备工作的核心底座。
但同步文件和同步行动不是一回事。
iCloud 可以让我在另一台机器上拿到同一份素材，却不能说明一个动作有没有执行、应不应该执行，或者哪台设备拥有权限。GitHub 可以让我接着阅读项目状态、审查差异和恢复历史，却不是一个适合在手机上完成高频个人行动的入口。我仍然要记住某段规则在哪个 Skill 里、当前状态在哪份文档里、某个 Agent 是否已经获得了足够的上下文。
更现实的是，很多高频动作仍然停在半自动状态。我可以让 Agent 理解账本、生成记录草稿，但记账经常还要回到飞书多维表格里手工完成。小红书流程能够生成文案、整理话题和辅助上传，却长期停在草稿或最终确认之前。
问题已经不再是模型会不会写。从“生成一个答案”到“对现实世界执行一次可以负责的行动”，中间还隔着身份、权限、状态、确认、外部结果和失败恢复。
Skill 很适合复用一个能力，但它通常依赖当前机器、当前会话和当前工具环境。我想做的 Personal Agent 要补上另一层：让同一组受控能力能够跨设备、跨 Agent、跨时间延续；让数据继续留在适合它们的权威系统里；让每一次行动都有明确的权限边界、结果证据，以及必要时的人工确认。
这不只是把更多 Skill 装进一个聊天窗口。
为什么是现在：这件事第一次对我变得可行
Personal Agent 不是突然冒出来的灵感。它在现在变得值得投入，是因为三个原本分散的条件刚好汇合了。
第一，vibe coding 大幅缩短了“我能判断一个系统应该是什么样”和“我能亲手把它做成可运行、可检查的东西”之间的距离。它没有让工程问题消失：服务、部署、权限、备份、测试和恢复仍然需要逐项面对。但它让我不必等到拥有一个完整团队，才能把产品判断变成原型、代码和真实反馈。对个人项目来说，它改变的是可行性，不只是速度。
第二，过去半年对 AI 的深度使用，让需求变得越来越具体。我不是先决定做一个“个人 Agent”，再给它寻找使用场景。顺序恰好相反：在聊天、搜索、Cowork、Coding Agent、知识库、脚本、iCloud 云盘和 GitHub 之间不断切换，一次次遇到上下文断裂、权限散落和行动无法闭环的摩擦之后，我才逐渐看清这套系统需要解决什么。
第三，公司里的 Agent 产品工作，让我更清楚“Agent 产品应该由产品决定什么”。模型可以提出意图，但产品必须决定它能看到哪些工具、哪些动作需要被策略拦截、什么证据才代表真正完成、什么时候应该把控制权交还给人，以及失败后系统如何停止和恢复。模型能力可以采购，Agent 的责任边界不能外包给模型自己。
这三个条件合在一起，才让我愿意把一组零散的 Skill 和自动化，升级成一个需要长期投入、也必须接受真实约束的系统。
我准备做的，不是另一个聊天机器人
Personal Agent 是一套只服务我自己的个人数据与行动系统。
iPhone 是最常用的入口，但不是系统的全部。真正的 Agent Runtime、会话、策略、自动任务、审计和 MCP Client 运行在自有服务端。账本继续留在飞书多维表格里，知识库继续留在 Obsidian 与 Git 里，未来的健康、衣橱、日历等数据也各自保留在最适合它们的系统中。
Agent 不负责再造一套“唯一数据库”。它要做的是在我授权的范围内理解这些系统、调用经过收窄和命名的业务能力，再把可核对的结果带回来。
例如，我在 iPhone 上说一句“午饭 45”。真正有价值的结果不是 Agent 回复“已经记好了”，而是系统正确理解日期、金额和分类，判断它不是重复记录，把它写入指定账本，再从飞书回读并返回可以核对的记录。如果表达有歧义、疑似重复或超出权限，它应该停下来问我，而不是猜一个看起来合理的答案。
这也是为什么我不把 iPhone 当成承载全部智能的设备。手机适合负责对话、展示、快捷动作、提醒与确认；高权限凭证、工具发现、连接治理、模型路由、审计和恢复应当留在服务端。未来即使入口从 iPhone 扩展到 Web、Mac 或其他 Agent，系统的核心能力与权限边界也不需要跟着迁移。
我希望最终拥有的不是一个替我聊天的角色，而是一层由我自己掌握的行动能力：
- 不需要先记住数据在哪里、应该打开哪个 App、调用哪个脚本；
- 可以在手机、电脑和不同 Agent 之间使用同一组受控能力；
- 低风险动作可以直接完成，敏感或不可逆的动作必须等待我的确认；
- 系统不能只声称“已经完成”，而要提供外部系统中可以核对的结果；
- 它可以逐步从被动问答，走向有边界的主动提醒和周期复盘。
这也是我为什么把它叫作 Personal Agent，而不是“个人工具箱”或“生活 Skill 集合”。Agent 意味着连续性和责任；工具箱只是一组彼此独立的能力。
Whole picture 不是未来需求清单，而是已有行为的重新组织
这个项目最终不会停在 Finance App。
它会逐步覆盖 Finance 与资产、知识库、Health、Wardrobe / OOTD、Calendar / Tasks / Reminders，以及需要由我最终确认发布的小红书等外部行动域。但这些方向不是我坐下来想象出的 AI 功能清单。
在 Agent 出现之前，它们就已经是我生活中反复发生的行为，只是分散在不同的数据源、设备和手工流程里：
| 已有行为 | 今天依赖的系统 | Personal Agent 要补的那一层 |
|---|---|---|
| 记账、查支出、月度复核 | 飞书多维表格 | 不是再造一套账本，而是接上自然语言入口、受控写入和结果核对 |
| 记录、检索和整理长期思考 | Obsidian、私有 Git、raw/ 与 wiki/ |
不是让模型“记住一切”，而是带着来源找到正确内容，并把新材料放到正确位置 |
| 查看健康与运动趋势、做月度复盘 | Apple Health / Apple Watch、体重记录 | 不是用聊天代替健康判断，而是减少导出、汇总和重复分析的摩擦，同时保留授权与隐私边界 |
| 管理衣橱、准备 OOTD、记录实际穿着 | iCloud 照片、索引、已有 Skill 和手工反馈 | 不是凭空生成穿搭建议，而是补齐推荐、实际穿着、清洁状态和下一次推荐之间的反馈 |
| 写小红书、整理图文素材、发布后归档 | 素材文件夹、草稿流程、知识库 | 不是让 AI 自动替我公开发帖，而是接好素材、草稿、页面填写和归档，把最终发布留给我 |
| 跨设备继续同一项工作 | iCloud 云盘、GitHub、项目状态文档和不同 Agent | 不是把所有文件和运行状态镜像到每台设备，而是分层同步稳定规则、项目事实和本机私密状态 |
| 维护个人项目、站点与长期任务 | GitHub、ECS、项目状态文档和不同 Agent | 不是再做一个项目管理工具，而是让我能从不同入口读到真实状态，并连续地推进下一步 |
所以，Personal Agent 的 whole picture 不是“一台 AI 替我管理人生”。它是把我已经在做、也会继续做的行为，逐步接到同一组可信的入口、权限和结果机制上。
这也意味着数据不应该被粗暴地汇总进一个新数据库。账本、知识库、健康记录、照片和项目仓库有各自的产生方式、保留规则和权威来源。Personal Agent 需要理解这些边界，并在得到授权时穿过它们，而不是为了形式上的统一抹掉边界。
第一条链为什么只做 Finance
Whole picture 可以很大，第一步必须足够小。
Phase 1 只做 Finance：支出、收入、家庭基金、查询和每日人工复核。它不如一个可以讨论所有生活话题的 Agent 炫，却同时具备这个项目最需要验证的条件：高频、跨设备、会产生真实写入、可以从自然语言进入，也可以从外部账本回读验证。
第一期刻意不做的事情同样重要：
- 不做面向公众或多租户的通用 AI 助手；
- 不在手机本地运行完整模型和 Agent loop；
- 不让模型直接获得裸文件系统、裸数据库或飞书全量权限；
- 不开放资产写入，不让 Agent 自动修改或删除知识库、衣橱等高风险数据；
- 不自动发布小红书、博客或其他公开内容；
- 不以“接入所有个人数据”为目标，也不在 MVP 中堆叠复杂的多 Agent 组织。
这些边界不是保守的功能取舍，而是产品定义的一部分。一个能够执行真实动作的 Agent，首先要证明自己会在不该行动的时候停下来。
我把 Phase 1 看作一次受约束的验证：先证明单 Agent 加上一组收窄后的业务工具，可以在真实设备、真实服务端和真实外部系统之间，稳定完成一次可核对的写入。只有这条链成立，后续领域才拥有值得复用的底座。
在写第一行业务代码之前，我先做了四类准备
回看提交记录，Personal Agent 的“开发开始”并不是第一行 Python 出现的那一刻。
在第一条正式生产代码 DEV-001 之前，仓库里已经有了一段完整的前史：PRD 与 ECS 基线、框架 Spike、Finance 规则、技术方案、评审修复、开发拆解和 G0 开发授权。
为了排除关键不确定性，我也写过一些 Spike：使用合成的记账表达、本地 MCP 测试服务和 GLM，分别验证 Google ADK 与 Claude Agent SDK 能否真正发现并调用工具。但这些实验只回答“这条路能不能走”，不直接承载真实账本，更不能把一次模型调用成功当成上线证据。
1. 先冻结 Finance 业务合同
“午饭 45”看上去是一条再简单不过的指令。真正写入账本时，问题却会立刻出现：今天和昨天如何计算？旅行、退款与 AA 收款怎样表达？哪些飞书字段可以写，哪些是公式或自动编号？同一天两笔相似支出应该判重，还是停下来询问？
所以在写连接器之前，我先定义 Finance MCP 的业务合同。模型负责把自然语言整理成结构化意图；日期、金额、分类、权限、幂等和风险判断由确定性代码处理；连接器只能访问指定年度账本中的指定字段。批量写入暂时关闭，因为当时没有证据证明数据源能够提供需要的全成全败语义。
这里还包含一个关键决定：不把通用的飞书官方 MCP 或任意飞书 API 直接交给模型。Agent 只能看到 finance.log_expense、finance.log_income、finance.query_expenses 这类按业务命名的工具。工具内部再经过策略、幂等和审计，由最小权限的飞书客户端调用原生 OpenAPI。
我复用官方 MCP SDK 来处理协议和连接，但自行设计 Finance MCP 与工具合同。前者避免重复手写底层协议，后者保证模型只得到“记账”所需的能力，而不是一整套通用飞书操作权限。
2. 用小而真实的 Spike 选择框架
我没有因为熟悉 Claude Code，就默认 Claude Agent SDK 应该成为项目运行时；也没有因为 Google ADK 支持 MCP，就直接相信它符合我的约束。
我更关心几个具体问题：GLM 能否真正调用 MCP 工具？框架能否保留模型可替换性？业务权限、工具目录、审计和确认逻辑能否留在框架外？未来更换模型或框架时，财务规则和系统状态是否需要一起迁移？
Spike 的结论是：两条路径都能跑通 GLM 与本地 MCP 测试服务。Phase 1 暂定 ADK-first，因为它更符合 GLM 优先、模型可替换和框架外治理这几个约束。Claude Agent SDK 保留为候选和对照。
更重要的决定是：业务权限由系统定义，不能由模型或 Agent 框架决定。Policy、MCP Client、连接器、审计和外部回执必须保持独立。这既是技术选型，也是为未来保留选择权的产品决定。
3. 在数据进入前加固现有 ECS
我已经有一台运行个人主页和旧项目的 ECS。最简单的办法是在上面再启动一个服务；但当 Personal Agent 可能接触账本、知识库和更多个人数据时，“服务器还在运行”远远不够。
在业务开发开始前，我先收紧了这台机器的基础边界：公网只保留必要入口，SSH 改为非 root 公钥登录，启用主机防火墙和自动封禁，公开站点与私有服务不共享部署身份和凭证。Tailscale 虽然验证可用，但可能与我在 Mac 和 iPhone 上已有的 VPN 冲突，因此没有成为移动端的必要依赖；默认方案改为 HTTPS、注册设备身份和短期访问令牌。
我还保留了加固前的回滚点，并把系统盘迁移到加密形态。这些工作不会出现在产品界面上，却决定了真实数据是否有资格进入系统。
4. 把 PRD 通过与开发授权分开
PRD 通过后，我没有直接进入功能开发，而是先制定技术方案设计计划。它要求依次回答：信任边界和部署形态是什么；请求在成功、取消、断线和响应丢失时怎样流转；服务端保存哪些最小状态与审计；Finance 如何冻结字段合同；密钥、服务身份、日志、备份和恢复怎样设计；最后才进入测试、灰度、回滚和任务拆解。
第一轮技术评审留下了三个 P0：端到端操作状态与崩溃恢复没有闭合；iOS 与服务端之间的设备认证协议不够具体；加密、密钥轮换和恢复验证缺少可执行合同。
它们都不能留给“代码写出来以后再调”。状态权威性不清，App 可能把已经写入的账务显示成取消；签名编码不冻结，Swift 与 Python 可能对同一个设备身份产生不同理解；备份如果不能证明可以解密，文件存在也不代表系统能够恢复。
这些问题被补进技术方案与开发拆解之后，项目才有了明确的 Go / No-Go 门、依赖顺序、失败条件和验收方式。G0 通过后，第一条正式生产代码才开始出现。
这些准备没有让我少写代码。它们把“我准备做一个 Agent”的想法，变成了一份对未知风险也设有停止条件的开发合同。
我为什么没有选择最简单的方案
做个人项目，永远存在更简单的路径。我可以继续把能力留在本地 Skill 和脚本里，可以让 iOS 直接连接某个 API，可以把记账做成一条单独的自动化，也可以完全依赖现成 AI 产品提供的 Connector。
但这个项目对我来说不只是尽快做出一个功能。我还想借它理解：一个个人 Agent 一旦进入现实环境，真正需要面对哪些边界。
| 更简单的路径 | 这次的选择 | 我想验证的问题 |
|---|---|---|
| 本地 Skill / 单机脚本 | 服务端 Agent Runtime + 受控 MCP 能力层 | 同一能力能否跨设备、跨入口和跨 Agent 使用，同时不把权限散落到每台机器上 |
| iOS 直接持有数据连接 | thin client / fat server | 手机能否成为主要入口，同时不承载高权限凭证和完整业务状态 |
| 把模型或框架当成完整 Agent | ADK-first、GLM-first，但 Policy、MCP 与连接器保持独立 | 模型或框架变化时，业务规则、权限与数据源能否继续保留 |
| 让模型使用通用飞书能力 | 自建 Finance MCP、业务工具和最小权限飞书客户端 | 能否把“记账”限制成固定业务动作，而不是把整套飞书操作权限交给模型 |
| 只在本地或模拟环境跑通 | 部署到真实 ECS，验证身份、隔离、备份与恢复 | 当真实数据和真实行动进入系统，“跑通”还缺少什么 |
这些选择会让项目慢下来，也会带来证书、部署顺序、文件权限、服务身份、密钥、备份和恢复等一长串玩具项目不一定遇到的问题。
但这正是我想学的部分。
过去半年，我一直在寻找更适合下一类任务的 AI 工具。现在，我想暂时停下扩充工具清单，开始建设一套连接能力、数据和行动的系统。
它的第一条链只从一句“午饭 45”开始。但我真正想弄明白的是：当 Agent 开始接触个人数据、跨设备工作并执行真实行动时，哪些复杂度可以被砍掉，哪些复杂度其实就是责任本身。