关于 Agent 的几点随想：协作、个人资产与场景差异
最近在使用和实现 Agent 的过程中，有几个想法越来越清晰，先记下来。它们还算不上一套完整的方法论，更多是我对 Agent 应该解决什么问题、个人又应该保留什么的判断。
一、Agent 的功能，可以沿着横向和纵向两个方向看
横向：打通平台，也打通人与人的工作
一个人的工作往往散落在很多平台里：在聊天软件里接到需求，在文档里查背景，在项目系统里跟踪任务，再到代码仓库或者业务系统里完成操作。平台各自都能用，平台之间的衔接却经常要靠人来做。
所以我觉得，Agent 的一类重要价值，就是把这些链路串起来。它需要知道的不只是某个平台的操作方法，还包括上一步的结果如何成为下一步的输入，以及这件事做到什么程度才算完成。
再往前想一步，工作链路里还有其他人。比如财务提供成本口径，业务负责人确认需求，设计师交付素材。从协作接口的角度看，其他人的工作，也可以被抽象成一个“平台”：我向对方提出请求，对方处理，再把结果交付回来。
但这样一来，真正有意思的问题就出现了：这个“其他人平台”，到底应该怎样定义？
我觉得至少需要说清楚：对方负责什么，需要我提供什么材料，有权决定什么，什么时候可能回复，以及什么样的回复才算完成。比如“找财务确认成本”，就远不如“请负责标准成本的同事，基于这份物料清单确认损耗口径，并说明适用范围”来得明确。
这里抽象的是人的协作方式。人的时间、判断和意愿，都需要被保留在这个接口里。请求可以被拒绝，可以要求补充信息，也可能需要转给另一个人。Agent 如果只学会发消息，却不知道如何等待、追问和交接，这条链路仍然没有打通。
研究里已经有相近的尝试。A2H：Agent-to-Human Protocol for AI Agent 这篇预印本提出用 Human Card 描述和发现人，并约定 Agent 何时、为何、通过什么渠道联系人。这和上面的想法有所呼应，不过，具体业务中的职责、授权和交付标准，仍然需要另外定义。
纵向：企业、项目和个人的要求如何共同生效
横向解决“和谁、通过什么系统一起做事”，纵向则要解决“按照谁的要求做事”。
企业有企业的规范，项目有项目的约定，个人也有自己的工作习惯。比如企业要求敏感数据不能外发，项目规定交付模板和审批流程，个人希望先看摘要、再看明细。Agent 执行一个任务时，这几层要求可能同时存在，也可能互相冲突。
所以，纵向打通不能只理解为把几份规范一起塞进上下文。还需要明确：哪些是必须遵守的边界，哪些是可以调整的默认配置，谁有权修改，例外由谁批准，以及更新后如何让正在执行的任务获得新要求。
我的倾向是：企业明确不可越过的边界，项目在边界内定义具体流程，个人再配置自己的工作方式。遇到冲突时，Agent 应该能够说明冲突来自哪里，并交给有权限的人处理。涉及访问权限的要求，还需要由实际系统执行。
横向是工作如何流转，纵向是要求如何生效。 这两个方向接起来，Agent 才有可能真正进入组织的工作过程。
二、Personal Agent 会很重要，因为记忆和 Skill 应该掌握在自己手里
我一直觉得，Personal Agent 会是一个非常重要的发展方向。
现在使用一个个 Agent 工具或平台，往往意味着要不断把项目背景交给它们：这个项目为什么这样做，之前否定过什么方案，我习惯怎样表达，哪些步骤已经形成了固定方法。用得越久，积累得越多，换平台时也越难带走。
这些东西里，项目记忆记录了我的工作经历，Skill 沉淀了我的工作方法。它们已经是个人资产的一部分。
至少对我自己来说，我更希望有一个本地的 Agent，让这些记忆和 Skill 在自己的电脑里形成闭环。我可以查看、修改、备份，也可以换一个模型或工具继续使用。我不希望换了平台，就要重新解释一遍自己，更不希望长期积累的方法只能在某个平台内部生效。
这也是我对 Personal Agent 的期待：它能够长期替我维护这些资产，再根据需要连接不同的工具和服务。模型可以换，服务可以换，项目积累能够留下来。
Letta 的 Context Repositories 已经在尝试用 Git 管理记忆，并让 Letta Code 在本地文件系统中保留记忆副本。这说明把记忆做成可管理文件是一条具体的技术路径。不过，它包含服务端和同步机制，不能直接等同于我期待的纯本地闭环。
我说的“本地”，主要是记忆和 Skill 的存储、维护与使用决定权在自己手里。调用云端模型时，仍然要决定哪些上下文会被发送出去；企业项目中的资料，也要遵守相应的归属和访问规则。
我没有依据断言所有用户都会这样选择。但对长期处理多个项目、不断积累工作方法的人来说，我判断，能够自己掌握这些资产，会成为选择 Agent 时越来越重要的理由。
三、Agent 的基本工程并不复杂，但没有统一的实现答案
从基本结构看，Agent 没有那么神秘：理解目标，选择工具，执行操作，根据反馈决定下一步。做出这个循环，本身未必需要一个很庞大的工程。
Anthropic 在《Building effective agents》 中也提到，成功的实现经常采用简单、可组合的模式，并建议根据实际效果逐步增加复杂度。我比较认同这个出发点。
但基本结构相似，不代表不同场景可以套用同一套实现。
比如一个工作类 Agent，可能需要围绕文档、表格、业务系统和审批流程来组织任务。它关心数据口径、权限、交付物是否正确，以及遇到问题后能否追溯。
一个视频类 Agent，则可能围绕脚本、分镜、素材、生成、剪辑和预览来组织任务。它需要处理画面与声音的一致性，也要支持用户反复调整某个镜头。它的任务状态、反馈方式和完成标准，都会和工作类 Agent 很不一样。
两者可以共享模型调用、任务记录等基础能力，但工具设计、记忆内容和执行流程，需要围绕各自的场景来做。把视频生成简单换成一个工具，未必就能让工作类 Agent 自然变成好用的视频类 Agent。
因此，我目前的判断是：Agent 的基本循环可以很简单，复杂度更多来自它要进入的具体工作。 稳定交付所需的权限、恢复、评估和交互，也会随场景变化。
如果以后自己做一个长期使用的 Personal Agent，我会先让它做好几条真实的工作链路，逐步积累自己的记忆和 Skill。至于它最终长成什么样，应该由这些具体工作来决定。