新项目开发相关讨论会议总结

会议时间：2026-05-25
原始记录：新项目开发相关讨论.txt
说明：原文为语音转写，部分项目名在转写中出现 renewmake、renew Mac、renumake 等不同写法。本文统一按“RenewMake”理解；cloud / Claude agent SDK 等表述按上下文整理为“Claude Agent SDK / Cloud Agent SDK”相关架构。

1. 会议核心结论

本次会议主要讨论新项目的 agent 运行架构、现有 RenewMake agent 能力的迁移方式、近期开发任务拆分，以及后续如何把新项目能力接入或迁移回 RenewMake。

核心方向是：

暂时先不在 RenewMake 上发布新功能，而是在新项目中完整实现原有核心 agent 能力。
新项目会作为一个 agent 运行平台，提供运行环境、API、SDK 调用方式，以及开发调试用的聊天 UI。
现阶段先验证“基于 Claude Agent SDK / Claude Code 的 agent 运行方式”是否能承接现有业务。
等核心能力验证完成后，再评估 RenewMake 是通过 API 对接该服务，还是直接迁移新项目核心代码。
原有 function 调用方式要逐步改为 MCP Server 调用方式。
近期优先实现找客户、产品推荐、Email、CRM 结合等核心场景。

2. 背景与目标

当前目标不是简单把 RenewMake 的代码复制到新项目，而是要把 RenewMake 中现有 agent 架构和 agent 核心架构替换成与新项目一致的架构。

迁移方式目前还没有最终决定，有两种候选路径：

通过 SDK / API 调用新项目服务
- 新项目托管 agent 运行环境。
- RenewMake 作为客户端，通过 SDK 或 API 创建 agent、创建 session、调用运行能力。
- 优点是 agent 基建可以独立维护。
- 风险是 RenewMake 中已有的自定义 agent、配置、数据库状态等可能需要和新项目重复维护或同步，流程复杂度较高。
将新项目核心代码重构后迁移进 RenewMake
- 直接把新项目的核心运行代码迁移到 RenewMake。
- RenewMake 原有的很多 agent 相关核心代码可能会被清理或替换。
- 之后只需要重点处理历史聊天记录、session 等数据格式迁移。
- 当前倾向是先把核心代码迁移过去，后续再视情况改成对接服务 API 的方式。

会议强调：现阶段不要过早决定最终集成方式，先在新项目中把原有业务能力完整跑通。

3. 新项目定位

新项目可以理解为一个 agent 运行平台，核心职责包括：

管理 agent 配置。
管理 agent 运行环境。
管理 workspace 和 session。
通过 SDK / API 供外部系统调用。
托管或连接不同的执行环境。
提供 MCP Server、技能、子 agent、工具等配置能力。
提供调试和观测能力，包括模型请求、工具调用、timeline、usage、上下文视图等。

会议中特别说明，项目内置的聊天 UI 本质上只是一个客户端工具：

它不是新项目最核心的业务本体。
它主要用于开发、调试和演示。
理论上外部系统可以直接通过 SDK / API 调用新项目，不一定需要使用聊天 UI。

4. 关键概念说明

4.1 Agent

Agent 在新项目中主要以配置文件或配置记录的形式存在。一个 agent 配置通常包含：

名称。
描述。
使用的模型。
系统提示词 / agent 提示词。
MCP Server 配置。
技能配置。
子 agent 配置。
工具配置。
权限配置。

当前会议中提到，实际配置可以先保持简化：

只配置必要的 tool set。
配置必要的 MCP Server。
权限默认可以设置为 bypass / allow flow，开发阶段先不做复杂权限检查。

Agent 支持版本化：

每次编辑 agent 后，会产生新版本，例如从 V1 变成 V2。
后续可以基于版本做效果评估和优化。
未来可能增加定时任务，检查 agent 运行效果，并对提示词和配置提出优化建议。

4.2 Session

Session 是一次具体对话或一次 agent 运行过程。

新建聊天 session 时，通常需要选择：

使用哪个 agent。
使用哪个 environment。
使用哪个 workspace。
是否绑定对应的密钥 / 凭证。

当前建议：

大多数业务场景下，每次新建对话就新建一个 workspace。
暂时尽量不处理一个 workspace 下运行多个 session 的复杂场景。
编码类场景可能会用到一个 workspace 下多个 session，但商机转化、找客户等业务场景应尽量依赖外部业务数据，而不是 workspace 内状态。

4.3 Workspace

Workspace 是 agent 运行时的工作目录或上下文空间。

会议中提到：

默认每次新建对话都会新建 workspace。
对于找客户、商机转化、产品推荐等业务流程，尽量让数据进入 CRM 或外部业务系统，而不是依赖 workspace 内部持久状态。
Workspace 更适合编码、文件处理等需要持续工作目录的场景。

4.4 Environment / Runner

Environment 用来描述 agent 的运行环境。它可以绑定不同的 runtime / runner。

当前提到两类运行方式：

托管沙箱环境
- 通过 npm run dev e2b 等方式启动时，可以使用类似虚拟机沙箱的运行环境。
- 该沙箱不是传统 Docker 容器，而是更隔离的虚拟化环境。
- 原因是 Docker 容器和宿主机共享内核，安全性需要额外配置。
本机 Runner
- 可以注册本机作为 agent 执行环境。
- 新建 environment 时选择自己的 runner，session 就可以运行在本机环境中。
- 这为未来“在云端操作用户自己的电脑”提供基础。
- 后续可结合微信、钉钉等本地软件，实现类似 OpenCloud 的远程控制能力。

环境还可以预设依赖：

NPM package。
Python package。
其他初始化脚本或运行前配置。

当前这部分还没有完全完善，但方向是支持环境初始化时自动安装依赖。

5. 凭证与 MCP Server 认证机制

新项目中有类似“保险箱”的凭证管理机制，用于管理 MCP Server 所需的密钥、token 等敏感信息。

工作方式大致如下：

在 agent 中配置需要使用的 MCP Server，例如 Exa Search、CRM、Email 等。
在凭证管理中为对应 MCP Server 配置密钥或 token。
新建 session 时选择对应 agent 和对应凭证。
agent 运行时不会直接把密钥暴露给沙箱。
请求会先进入项目自身的 server 网关。
网关代理实际 MCP 请求，并在代理层注入密钥。

这样做的目的：

密钥不直接暴露给 agent 沙箱。
凭证可以按个人管理。
MCP Server 的认证可以统一通过服务端代理处理。

会议中有人询问 MCP 认证和系统内 access key 是否有关。答复是：有关系，但当前阶段可以先把新项目当作个人客户端来调试，每个人配置自己的密钥。等后续新项目作为 RenewMake 的服务端或后端使用时，再正式处理组织级、用户级权限和凭证体系。

6. 调试与观测能力

新项目内置了多个调试视图，用于观察 agent 运行过程。

6.1 Summary 视图

用于显示较简洁的对话摘要：

用户消息。
工具调用。
简化后的运行过程。

6.2 Timeline 视图

比 summary 更详细，包含：

模型调用。
工具调用。
运行事件。
请求链路。

模型调用默认不直接展示完整上下文，但可以通过“查看真实请求”查看实际发给 LLM 后端的请求内容。

6.3 真实请求拦截

项目内置了网关代理，类似 LiteLLM 网关层。

运行链路大致为：

用户发消息。
消息进入 Cloud / Claude Agent SDK。
Agent SDK 在沙箱或 runner 中运行。
SDK 配置的 base URL 指向新项目自身网关。
网关拦截请求并记录信息。
网关再转发给实际 LLM 后端。

这样可以看到：

实际发给模型的系统提示词。
实际上下文。
模型请求参数。
usage 和计费信息。

会议中特别提到，Claude Code / Claude Agent SDK 预设系统提示词值得关注，因为它们在工程化程度上比之前手工拼装提示词的方式成熟很多。

6.4 全事件视图

全事件视图展示 agent 运行过程中从 runner 到 server 的全部事件。

当前问题：

事件量大时比较卡。
后续可能优化存储策略。
可能只保存部分时间，例如超过 30 天自动删除。

6.5 Claude 视角上下文视图

该视图用于模拟 Claude 实际看到的上下文。

例如：

如果上下文被压缩，模型实际看到的内容会和原始消息不同。
该视图可以帮助开发者理解压缩后的上下文状态。

6.6 导出能力

目前有两类导出：

下载原始 JSON 文件。
导出为 Claude Code 支持的 session 持久化格式。

Claude Code 本身也通过文件保存 session。导出后可以把 session 放到其他地方做调试。

6.7 Usage 统计

Usage 页面展示网关层的调用统计和计费信息，包括：

每次模型调用。
token 使用情况。
费用统计。

7. Web Search 与工具调用

项目中内置了 web search 能力。

背景：

Anthropic 和 OpenAI 的模型通常支持官方内置搜索。
Claude Code 默认可能调用 Anthropic 的搜索能力。
但第三方模型，例如 DeepSeek，未必支持官方搜索工具。

当前实现：

在网关层拦截官方搜索工具请求。
将官方搜索工具转换成自定义搜索工具。
对客户端来说，看起来仍然是原生搜索工具。

后续方向：

当前搜索能力可以作为兜底。
未来更倾向于使用 Exa 等外部搜索 MCP。

8. MCP Server 与工具体系改造

会议强调，接下来要把原来 function 调用的方式改造成 MCP Server 调用方式。

这意味着：

原有工具不能简单照抄。
可以参考旧实现，但应该基于新架构重写。
MCP Server 要作为独立服务来设计。
数据该进入 CRM 的就进入 CRM。
工具之间不应依赖旧 UI 或页面内嵌状态。

例如 Email MCP Server 不能依赖用户在页面内上传文件、页面组件状态或固定前端逻辑。它应该提供可被任意 agent 调用的独立接口。

9. Email 功能讨论

Email 是本次会议重点讨论的业务模块之一。

9.1 草稿编辑与保存

此前 Email 草稿修改后没有保存的问题已经被调整，目前可以通过 API 实现自动保存。

草稿保存涉及两层：

服务端草稿保存
- 用户修改 Email 组件内容后，内容会保存到服务端。
- 也会保存到 RenewMake 项目的数据库结构中。
上下文状态记录
- MCP Server 会向 agent 上下文写入一条状态消息。
- 但它不会直接修改模型上下文中原有的草稿内容。
- 例如会写入类似“某草稿已产生修改，后续请重新获取”的状态。

设计原则：

模型不应依赖自己上下文里的旧内容作为最终草稿内容。
草稿内容应以草稿 ID 对应的服务端内容为准。
Agent 提示词中要约束：使用草稿时，应根据 ID 重新获取最新内容。

9.2 邮件发送状态

如果邮件已经发送，MCP Server 也应该向上下文写入状态，告诉 agent 该草稿或邮件已经发送，避免重复操作。

9.3 附件能力

原有附件处理与页面耦合较深，迁移为独立 MCP Server 后需要重新设计。

需要考虑：

附件应作为 Email MCP Server 的独立字段。
Agent 可能需要先上传文件，再把文件 URL 作为附件传给 Email MCP。
可能需要提供“生成预签名上传链接”的 MCP 工具。
该工具可以放在 Email MCP Server 内，也可以做成独立 MCP Server。

9.4 内嵌图片

内嵌图片需要单独设计约定。

问题点：

不能简单让 agent 在 HTML 中写 <img src="...">。
Email 发送时，内嵌图片通常需要转换成邮件附件格式。
MCP Server 端需要负责把某种约定格式转成符合 Email 标准的附件结构。

可能方案：

自定义一种 attachment image 语法。
使用占位符方式描述内嵌图片。
MCP Server 在发送前统一转换。

9.5 EML 格式扩展

会议中提出可以考虑直接构建 EML 文件。

EML 是标准邮件格式，可以保存：

邮件 header。
邮件 body。
收件人。
发件人。
附件。
内嵌资源。

但该方案作为扩展考虑，因为如果直接基于 EML，后续编辑体验和修改操作可能会更复杂。

10. 记忆功能

新项目中会提供新的记忆实现。

记忆将作为预置能力注入 agent 或 session：

新建 agent 或 session 时，可以启用记忆。
启用后，会注入记忆相关工具。
每次对话开始时，agent 会先搜索记忆。
每次运行结束时，agent 会保存记忆或生成总结。

该设计类似 Codex 中可启用的记忆功能。

11. Hooks / 钩子机制

会议中特别提到 Claude Agent SDK 中的 hooks 很有价值，未来应多研究并使用。

示例：找客户场景。

如果 agent 找到了 10 到 30 个客户，业务上要求这些客户应该进入 CRM。

可以预设一个运行结束后的 hook：

Agent 输出结果后触发 hook。
Hook 检查 agent 是否调用过插入 CRM 的工具。
如果没有调用，则提醒或驱动模型补充调用。
如果已经调用，则不重复操作。

这类 hook 能帮助保证业务流程闭环，减少模型只输出文字但不写入业务系统的问题。

12. 架构选择与长期方向

会议对当前架构选择做了较多解释。

12.1 为什么使用 Claude Code / Claude Agent SDK

主要原因：

Claude Code 工程化程度较高。
其系统提示词、hooks、subagent、权限控制、交互机制等已经比较成熟。
更新频率高。
比团队自己维护 agent loop、提示词拼装、工具调用循环更稳定。

12.2 当前方式并不是最终最先进架构

会议中提到，行业方向可能正在从“把整个 agent SDK / Claude Code 跑在沙箱里”转向：

agent loop 运行在服务端。
工具运行在沙箱中。
agent loop 和工具执行环境分离。

这其实更接近团队之前在 RenewMake 中的做法。

但当前问题是：

这种新方式整体还不够成熟。
自研 agent loop 的工程化效果不如 Claude Code。
需要先把管理平台、配置协议、运行流程稳定下来。

因此当前选择是：

先“退一步”，把 Claude Code / Agent SDK 和沙箱环境绑定起来运行。
先借助 Claude Code 成熟能力完成业务迁移。
等平台稳定后，再考虑拆分 agent loop 和工具沙箱。

12.3 Claude Code 的局限

Claude Code 也存在限制：

不允许完全自定义工具运行方式。
工具不能按理想方式单独运行在沙箱中。
更像是把自身进程运行在沙箱中。

但在当前阶段，它仍然是 agent 工程化较成熟的选择。

13. 近期开发任务拆分

接下来几天优先在新项目中实现原有核心 agent 能力，不急于往 RenewMake 发布新功能。

13.1 主要任务

模块	任务内容	负责人 / 分工
CRM	完成 CRM 相关 MCP 能力，并与后续 agent 结合	小关
产品推荐	实现产品推荐相关 agent / MCP 能力，并与 CRM 结合	小关
Email	完善 Email MCP Server，包括草稿、附件、内嵌图片等能力	朱晨
找客户 / 客户分析	先分配给朱晨，但顺序上可在 Email 完善后再做	朱晨
Agent 初始化脚本	为几个核心 agent 提供初始化配置脚本	需要协作
MCP 修复	如果 RenewMake 中现有 MCP Server 有问题，需要同步修复	对应模块负责人

13.2 实现顺序建议

先完善 Email 能力。
同步推进 CRM 和产品推荐。
再实现找客户 / 客户分析。
核心能力跑通后，再迁移全部 agent。
最后评估 RenewMake 对接新项目 API，还是迁移新项目核心代码。

13.3 初始化脚本

需要提供脚本来初始化核心 agent 配置。

脚本职责包括：

创建 agent。
导入 agent 配置。
导入技能文件。
配置 MCP Server。
创建或关联密钥。
方便团队成员共享配置并调试。

该脚本先放在当前新项目中。

会议中提到，新项目本身的核心代码暂时不应大改；主要代码调整应集中在：

RenewMake 中的 MCP Server 代码。
新项目中的 agent 初始化脚本。
少量必要 bug 修复。

14. 开发协作规范

14.1 分支与 PR

当前在 main 分支开发，并通过 PR 提交。

14.2 不要照抄旧实现

会议强调：

可以参考原有实现。
但不要直接抄旧代码。
应按新项目、新架构重新实现。
原本 function 调用要改为 MCP 调用。

14.3 测试与反馈

开发完成后要尽量通过截图分享运行效果，尤其是新项目中的 agent 运行效果。

原因：

很多业务代码仍在 RenewMake。
新项目主要验证 agent 配置、MCP 调用和运行效果。
截图可以帮助团队快速判断效果是否比原来更好。

14.4 本地调试与上线验证

调试建议：

日常调试可以运行本机 runner，速度更快。
上线前验证要连接 e2b 沙箱。

环境变量：

当前密钥基本已写入环境变量。
如果发现缺失，需要及时反馈。

沙箱配置：

环境变量中支持两类沙箱配置：七牛和 e2b 官方。
国内后续倾向使用七牛提供的能力。
两者基本兼容 SDK，只有部分场景可能不兼容。

Local runner：

如果需要调整 local runner 代码，需要重新 build 并重启。
当前一般不需要改 local runner。

15. 后续迁移计划

整体迁移路径分为几个阶段。

阶段一：在新项目中实现核心 agent

包括：

找客户。
产品推荐。
Email。
CRM 结合。
相关 MCP Server。
初始化脚本。

目标是验证新项目架构可以承接 RenewMake 核心能力。

阶段二：迁移全部 agent

将所有 agent 配置迁移到新项目对应服务的数据库中。

迁移后再统一评估：

是否通过 API 让 RenewMake 对接新项目。
是否把新项目核心代码迁移到 RenewMake。

阶段三：处理 RenewMake 集成

如果采用核心代码迁移方式：

RenewMake 中原有 agent 核心代码可能直接删除或替换。
新项目核心代码重构后迁入 RenewMake。
重点处理原有数据库、session、聊天记录到新格式的适配和迁移。

如果采用 API 对接方式：

RenewMake 需要管理自身 agent 配置。
同时需要同步到新项目服务。
需要处理配置同步、权限、组织、用户、凭证等复杂问题。

当前倾向：

先迁移核心代码到 RenewMake。
等 RenewMake 侧稳定后，再考虑转为对接新项目 API。

16. 风险与待解决问题

16.1 架构集成方式未最终确定

API 对接和核心代码迁移各有优劣，目前先通过业务实现验证再决策。

16.2 MCP Server 独立化改造成本

原有功能可能和 UI、页面状态、旧 function 调用耦合较深。迁移成 MCP Server 后，需要重新设计接口边界。

16.3 Email 附件和内嵌图片设计未定

需要确定：

文件上传工具放在 Email MCP 内还是独立 MCP。
附件字段如何表达。
内嵌图片如何约定。
是否需要支持 EML 构建。

16.4 Debug 视图仍有 bug

调试 UI 中部分交互还没有完成或存在 bug，例如 ask user question 弹窗等。

16.5 全事件存储和性能问题

全量事件展示比较卡，后续需要优化：

存储时长。
查询方式。
UI 展示方式。

16.6 组织级权限和凭证模型待设计

当前先按个人客户端调试。未来作为 RenewMake 后端服务时，需要正式设计：

组织级密钥。
用户级密钥。
权限隔离。
凭证继承和授权。

17. 行动项清单

优先级	行动项	负责人 / 备注
高	在新项目中创建核心 agent 配置，并提供初始化脚本	团队协作
高	完善 Email MCP Server，重点处理草稿保存、上下文状态、附件、内嵌图片	朱晨
高	实现 CRM MCP 能力，并保证业务数据进入 CRM	小关
高	实现产品推荐 agent / MCP，并与 CRM 结合	小关
中	实现找客户 / 客户分析 agent，并与 CRM 写入流程结合	朱晨，Email 后推进
中	修复 RenewMake 中现有 MCP Server 的可用性问题	对应模块负责人
中	研究并使用 Claude Agent SDK hooks，保证关键业务流程闭环	团队协作
中	优化调试 UI，参考 Codex 的工具调用折叠、详情展示和 debug 面板样式	待安排
中	优化全事件视图性能和事件保存策略	待安排
低	评估 EML 构建方式对 Email 编辑和附件处理的价值	Email 模块后续扩展
低	后续评估 agent loop 与工具沙箱分离架构	平台稳定后再考虑

18. 面向团队的执行提醒

接下来几天优先在新项目高速迭代。
不急于在 RenewMake 上发布新功能。
原有工具调用要迁移为 MCP Server 调用。
旧代码只作为参考，新实现应围绕新架构重新设计。
数据该进入 CRM 的必须进入 CRM，不能只停留在模型输出里。