做过智能体平台的人，大概率都会遇到一个问题：系统越来越强，但用户还是不会配。 不是按钮不够多，而是用户在真正开始配置之前，先要做一堆判断：这个智能体职责怎么收口、System Prompt 怎么写、要不要加工具、工具该加到什么粒度、改一句提示词还是得补一个 API 能力。对很多人来说，真正难的不是录入，而是设计。
这次 Cogent 上的新功能，想解决的正是这一层问题。我们没有再往左侧面板里塞更多开关，而是在右侧新增了一个“构建模式”：用户直接描述想要什么样的智能体，AI 先理解需求，再生成一个可预览、可确认、可应用的配置 patch，最后一键落回左侧表单。
以前的问题，不是不会填表，而是不知道该怎么下手
如果只看上一版 Builder，它其实已经把配置成本压得很低了：左边配，右边测，工具、Skills、MCP 都能可视化开关，Prompt 也有 AI 辅助。但对第一次做智能体的人来说，这仍然有明显的起步门槛。
所以这次升级的重点，不是把表单变得更花哨，而是把“智能体设计的第一轮脑力活”也纳入平台。用户先说目标，系统再帮他把目标翻译成 AgentConfig 里的结构化内容。
这次升级，真正多出来的不是聊天，而是一个配置闭环
如果只是做一个对话框，AI 回答“建议你新增一个工具、优化一下 prompt”，那很快就能做完。但这种方式有一个明显问题：建议不会自动变成配置。 用户还是得自己回到左侧，把建议手工抄一遍。链路断了，价值就只剩下“参考”。
这套链路一旦成立，右侧面板就不再只是“聊天辅助”，而是 Builder 真正的一部分。AI 说的每一句话，最终都要能落到字段级变更上。
这里其实有一个很典型的产品分界线。很多“AI 辅助配置”最后都停留在建议层，用户看完觉得挺对，但依然得自己切回表单逐项录入。录入这件事一旦没被消灭，认知负担就只是从“不会设计”变成“会设计但很烦”。所以这次我们在前端上坚持了一个原则：右侧的每一次生成，都必须有明确的数据去向。 要么形成 patch 预览，要么形成 warnings，要么形成 questions，不能只剩一段漂亮但不可应用的话。
前端变了什么：右侧从“测试面板”升级成“构建工作台”
这次前端层面的变化非常明确：AgentBuilderTestPanel 不再只是测试入口，而是变成了一个双模式面板。顶部多了 构建 / 测试 切换，空状态提示、输入框占位、历史会话逻辑、补充能力入口，全部围绕这两个模式重新组织。
这里有个很重要但容易被忽略的产品细节：构建模式和测试模式用的是两条不同的工作链。测试模式必须依赖保存后的配置 ID；构建模式则可以在还没发布之前，先围绕当前草稿反复生成和调整方案。这让“先想清楚，再落配置”成为可能。
双模式的意义不只是“多了一个 Tab”。它背后其实对应两种完全不同的心智模型。测试模式里，用户默认认为左侧配置已经相对稳定，右侧只是验证器，所以重点是会话、历史线程、模型参数和运行结果。构建模式里，用户还处在设计阶段，右侧就不能只是一个聊天窗口，而应该像一个设计助手：给出建议、展示 patch、解释影响范围、允许应用回填。也正因为这个差别，构建模式里我们额外放了 HAR 上传入口、Patch Preview、应用按钮，以及针对 build 场景的建议提示词。这些细节拼起来，右侧面板才真正从“对话区”升级成“工作台”。
另一个很关键的设计是应用后的可见反馈。如果 AI 生成 patch，用户点了“应用到左侧”，页面却只是默默改了几个字段，体验会非常虚。前端这次专门做了受影响区块高亮和能力 Tab 定位，本质上是在回答两个问题：系统到底改了哪里？这次改动是不是我预期中的那部分？对于配置型产品来说，生成能力重要，但“改完以后用户能不能看明白”同样重要。
// 右侧面板已经不只是测试，而是同时承担构建入口
<AgentBuilderTestPanel
v-model:mode="rightPanelMode"
:saved-agent-id="savedAgentId"
:build-context="buildAiContext"
@apply-patch="applyAiPatch"
/>
// AI 读取的是当前 Builder 上下文，而不是自己查库
function buildAiContext() {
return {
current_config: buildPayload(form.status || 'draft'),
available_tools: BUILTIN_TOOLS_META,
available_skills: availableSkills.value,
available_user_skills: availableUserSkills.value,
available_mcp_servers: availableMcpServers.value,
}
}
这段代码背后的意思其实很重：构建 Agent 不被允许“脑补”平台里有什么，它只能依据当前 Builder 页面给它的上下文做决策。这一下把能力边界卡得很清楚，也让前端能控制 AI 的输入质量。
后端变了什么：不是多一个 Prompt，而是多一个专职构建 Agent
要把右侧面板真正做成构建工作台，仅靠前端是不够的。后端这次没有复用某个现成业务 Agent，而是单独做了一个 agent_builder_agent。它的职责很克制：
-
不查数据库 -
不直接保存 -
不直接发布 -
不直接运行用户想新增的工具代码 -
只输出 Agent Builder 能应用的草案或 patch
这个 Agent 更像一个“配置生成器”，而不是一个业务执行器。它只负责把需求翻译成配置，不代替页面完成状态变更。这样做的好处是：链路短、边界清、风险可控。
# 产物不是文件，也不是数据库记录，而是结构化 patch
SYSTEM_PROMPT = """
你是 Cogent 智能体构建向导。
你的产物不是文件，也不是数据库记录，而是
可应用到 Agent Builder 左侧配置面板的 AgentConfig 草案或结构化 patch。
1. 不查数据库
2. 不保存、不发布
3. 先汇总确认，再生成方案
4. 只选可用能力
5. 默认最小修改
6. 生成 patch 前先确认
"""
agent = create_deep_agent(
model=model,
tools=[],
system_prompt=SYSTEM_PROMPT,
skills=[GUIDE_VIRTUAL_PATH],
backend=backend_factory,
)
这里最值得注意的点有两个。
第一，**tools 传空**。也就是说这个构建 Agent 默认不靠外部工具去“主动干活”，而是优先读取挂载进来的方法论 skill。它的强项不是查资料，而是按规则做配置规划。
第二，**skills 只挂了一个：/skills/agent-builder/**。这说明这次升级的核心不在模型换得多强，而在于“构建智能体的方法”被沉淀成了一套可读、可维护、可迭代的技能目录。
从智能体设计角度看，这种拆法也很有价值。很多平台在做“AI 帮配置”时，会把配置生成、接口分析、工具开发建议、测试反馈优化全部压进同一个大 prompt，最后 Agent 的角色越来越混乱：一会儿像产品经理，一会儿像 Prompt 工程师，一会儿又像接口封装助手。现在单独拉出 agent_builder_agent 之后，角色边界就清楚了。它不是业务执行 Agent，也不是通用问答 Agent，它只做一件事：围绕当前 AgentConfig 产生最小且可应用的配置变更。
这个设计还有一个隐藏好处，就是让前端和智能体之间形成了稳定契约。前端负责提供真实上下文，例如当前配置、可用工具、可选 skills、可挂 MCP、当前空间；构建 Agent 负责基于这些上下文输出标准结构；真正的保存、发布、测试仍由原有页面流程负责。这样一来，AI 层即使未来继续增强，比如增加更复杂的工具设计能力、支持更强的 HAR 分析能力，也不会破坏 Builder 本身的主流程。系统的“智能”被装进了一个边界清晰的模块里，而不是渗透到整条保存链路中。
真正的价值，在于这次把“做智能体的方法”做成了 Skill
这一点是我认为最值得讲的部分。过去很多团队做“AI 帮生成配置”，最后都容易掉进一个坑：把所有规则糊进一个超长 prompt。短期能跑，长期就很难维护，任何新需求进来都得继续往那段 prompt 里打补丁。
这次 Cogent 没这么做，而是把构建流程拆成了方法论节点。比如：
-
S1需求澄清 -
S2能力设计 -
S3AgentConfig 草案 -
S5Patch 输出规范 -
S7测试反馈迭代 -
S9工具设计 -
S10HAR / API 接口分析
为什么要坚持“先确认，再生成 patch”
很多人第一眼看到这个功能，直觉都会是：既然 AI 都能生成配置了，为什么不让它直接改完？从产品爽感看，当然是一句话就全自动最好。但智能体配置和普通文本不同，很多字段一旦改错，影响是立刻可见的：
-
新增高风险工具，可能改变行为边界 -
重写 System Prompt，可能覆盖掉本来可用的约束 -
直接返回整段 tools_config，可能误伤已有工具列表 -
根据 HAR 生成一批接口工具，如果没先梳理关系，很容易堆出一堆“能配但不好用”的能力
所以这次我们把“确认”做成了流程的一部分。AI 不是上来就吐 JSON，而是先告诉你：
-
准备改哪些字段 -
为什么这么改 -
哪些属于高影响变更 -
是否确认继续生成 patch
为什么工具要用增量 patch，而不是每次回整段配置
这是一个很工程、但又很影响体验的细节。对于新增、删除或修改单个工具，这次后端没有默认返回整段 tools_config，而是引入了 patch_ops 协议，比如 upsert_tool 和 remove_tool。
{
"assistant_message": "新增订单状态查询工具，并补充调用边界。",
"patch": {
"system_prompt": "...新的工具调用规则..."
},
"patch_ops": [
{
"op": "upsert_tool",
"key": "query_order_status",
"value": {
"type": "http",
"name": "query_order_status",
"method": "GET",
"url": "https://internal/api/orders/{order_id}"
}
}
],
"warnings": ["内部接口需要确认鉴权方式"]
}
这样做的价值很现实：用户只是补一个工具，不应该把现有整套工具配置全部重写一遍。增量 patch 让 Builder 能更稳地合并改动，也让用户更容易相信“这次只动了我想动的部分”。
这次能力上线后，平台表达方式变了
以前平台告诉用户的是：你可以来这里配置一个智能体。现在平台开始告诉用户：你先描述你想要什么，我们帮你把它落成一个智能体。听起来只差几个字，但产品姿态其实完全不同。
前一种模式，是用户先理解系统，再使用系统；后一种模式，是系统先理解用户，再把能力组织出来。
这也是为什么我觉得这次升级值得单独写一篇。它不是又加了一个功能点，而是 Builder 从“配置器”开始往“构建器”走。接下来用户做智能体，不一定要从空白 Prompt 和一堆 schema 开始，而是可以先从一句业务目标开始。
真正成熟的平台，不只是把能力摆在那儿，更要主动帮用户降低使用这些能力的认知成本。Builder 之前解决的是配置承载问题，这次开始解决构建起点问题。