Agent Memory 最常见的实现，是每隔几轮让模型总结对话，把摘要写进向量库。这样很快会混进三类完全不同的数据：用户所在城市这类事实、偏好中文回答这类偏好、任务执行到第三步这类运行状态。它们的正确性、有效期和删除规则并不相同。

我会先拆数据模型，再谈 embedding/召回。事实需要来源和时间，偏好需要用户可见可改，运行状态需要强一致的 checkpoint。三层都可以进入上下文，但不能共用“相似度高就拿出来”的读写规则。

OpenAI 昨天宣布 Responses API 支持 remote MCP servers。对 Agent 平台来说，这会显著降低远端工具接入门槛，也带来一个直接问题：用户或模型提供的 MCP URL，能不能马上连接并把工具放进上下文？我的答案是否定的。

MCP 协议兼容只证明双方能交换消息，不证明 Server 的身份、代码、权限和数据处理值得信任。我会用 Trust Registry 把“发现一个 URL”与“允许某类用户在某类 Run 中连接”分开。

数据平台接 MCP 时，最吸引人的 Demo 是让 Agent 直接“重跑这个任务”或“补最近七天数据”。但执行链涉及对象歧义、生产权限、依赖、资源和覆盖风险，任何一层不成熟都会把模型错误变成真实操作。

我更愿意从元数据查询开始：找表、看字段、解释 owner、查函数、展开一两层血缘。它是低副作用场景，同时能逼出 MCP Server 最关键的基础能力：稳定对象身份、权限过滤、版本、新鲜度、分页和证据返回。

MCP Server 很容易从“先把能力接出来”变成一个通用执行面：提供 run_command、query_sql、http_request、read_file(path)，模型似乎什么都能做。开发效率高，安全和可验证性却都变差，因为一个字符串参数就能跨越大量对象和副作用。

我会把 MCP Server 当成业务 Facade，不是内部 API 的透明代理。Resources 用稳定 URI 暴露受控上下文，Tools 表达窄业务动作，Prompts 只是用户可选模板。通用能力留在受限开发环境，不作为企业生产 Server 的默认接口。

Agent Trace 如果只记录“模型调用了 rerun_job”，事故复盘时会留下一个模糊结论：是模型决定重跑，还是工作流规则要求重跑，用户是否确认，权限系统为何允许，后端到底有没有执行成功？这些责任不能压进同一个 tool call span。

我会把建议、授权、编排选择、人工批准和实际操作拆成不同 Decision/Operation 事件。每条记录 actor、输入快照、规则或模型版本、证据与结果。这样可以回答“谁在什么依据下推进了哪一步”。

OpenAI 3 月 11 日发布 Responses API，把 Chat Completions 的简洁接口与工具使用能力放进新的 API primitive，并提供 web search、file search、computer use 等内置工具。统一 item 结构和流式事件会减少很多自建编排代码。

但供应商帮我们统一模型与内置工具，不等于企业内部动作也能直接托管。用户身份、对象权限、生产状态、审批、幂等和回滚仍属于企业执行域。我会把 provider response 和 business operation 分成两套身份与状态，再在 Run 最终化阶段汇合。

OpenAI 2 月 2 日发布 deep research 后，长时间自主搜索和综合大量来源的研究 Agent 进入产品视野。连续搜索几十次只是执行表象，真正困难的是回答两个问题：核心结论是否已有足够证据，继续搜索是否还会改变结论。

我把研究过程组织成 Claim-Evidence Ledger。先把研究问题拆成可核查主张和所需证据类型，每轮搜索填补覆盖缺口、查找反例或验证来源；达到预先定义的收敛条件才结束，不以网页数、token 或运行时长作为完成标准。

Agent 接了十个工具后，最省事的做法是给运行服务一个能访问十套系统的账户，再靠 Prompt 告诉模型“只做用户允许的事”。这会把服务账户的最大权限变成每次对话的潜在权限，任何 Prompt Injection、对象误选或编排 bug 都能放大影响。

我希望权限按 Run 和 Step 临时收敛。当前用户、当前任务、当前步骤真正需要什么能力，就签发什么短时 capability。服务账户只是基础设施连接身份，不代表模型自动拥有它能做的所有事。