一个能长期工作的 Agent不是一段越来越长的系统提示词。它至少要分清规则、资料、Skill、工具、执行入口和测试反馈。我想做的东西并不复杂给它一个主题它先搜集可核验的资料再整理文章大纲最后生成适合不同博客平台的版本。还有一条硬要求可以把内容预填进编辑器但不能替我点下最终发布。最开始我以为只要写好 Prompt 就够了。于是把账号定位、写作要求、平台规则、事实边界和发布流程全塞进系统提示词。短期看它确实能跑改过几轮之后问题却越来越多规则互相打架平台要求难以维护资料更新要改 Prompt工具报错时也不知道该在哪一层处理。这时我才意识到Prompt 只是 Agent 的一部分。一个能重复执行的 Agent更像一套小型软件系统。先定义一个足够小的任务不要一上来就做全能内容运营。我给第一版 Agent 只留一个目标输入主题和目标读者基于可核验资料形成文章再生成平台版本信息不足时追问涉及真实发布时停下来等待人工确认。这个定义故意删掉了热点监控、自动配图、评论运营等能力。目标越多越难判断一次失败到底来自模型、资料、工具还是流程设计。最小链路可以画成这样用户输入 - Agent 判断任务与缺失信息 - 读取相关资料和 Skill - 调用搜索、文件或博客预填工具 - 验证工具返回 - 输出结果或请求人工确认Prompt 只放长期稳定的规则系统提示词适合保存不应频繁变化的内容角色、目标、事实边界、确认点和输出结构。例如你是内容运营 Agent。 只使用用户资料或可追溯来源陈述事实来源不足时明确标注。 先给出大纲再生成正文。 博客工具只用于预填未经用户新一轮明确确认不执行真实发布。 工具未返回成功结果时不得声称操作已完成。至于知乎开头要先回答问题CSDN 代码块如何处理这类平台细节不必全部硬塞进 Prompt。否则每增加一个平台系统提示词都会膨胀一轮。资料负责事实Skill 负责方法我把账号定位、目标读者、品牌禁用词和历史高质量文章放进资料层。它们是 Agent 工作时要参考的事实而不是行为指令。把资料和指令分开有两个好处。第一资料更新时不用改系统规则第二可以按任务只取相关内容避免每次都把整个资料库塞进上下文。Skill 则适合封装可复用的方法例如文章事实核验流程或四平台改写规范。一个 Skill 可以包含执行说明、检查表、脚本和参考资料。只有任务命中时再加载细节比在 Prompt 中常驻所有规则更节省上下文。这里还要区分两种用法强制能力每次都必须执行例如事实核验可选能力特定任务才调用例如改写成掘金版本。如果所有 Skill 都强制注入最终只是把超长 Prompt换了一个存放位置。工具和 MCP 要有稳定契约工具不是一句帮我搜索一下。它应该有明确输入、输出和失败结构。{input:{query:string,timeRange:optional,maxResults:10},output:{status:success | partial | failed,items:[],issues:[],traceId:string}}普通工具适合稳定、单一的动作。MCP 适合把搜索、文件、博客预填或业务 API 以统一方式接进 Agent。无论哪一种关键都不是能调用而是失败后能不能说清哪个字段错了、是否部分成功、还能不能重试。在一个编辑器里把各层装起来完成分层后我在 Tipkay 的 Agent 编辑器中配置模型、系统提示词、工具、客户端/服务端 MCP、Skill 和资料并在同一个页面里用右侧会话测试。这里 Tipkay 承担的是搭建与测试环境不替代前面的架构设计。下面两张图来自 Tipkay 的真实创建页。为避免改动线上应用我只在未保存的表单中装入测试配置第一张展示模型、系统提示词、工具与 MCP第二张专门展示 Skill 可选池、强制注入池和资料绑定策略。右侧测试区与配置区保持同屏。三组测试比感觉不错更可靠我会固定测试三类输入。第一类是正常主题资料齐全、来源明确检查它能否按流程形成大纲和平台版本。第二类故意缺少来源例如要求写一个没有提供数据的增长案例。正确行为不是补一个看似合理的数字而是追问或留下证据槽位。第三类要求它直接发布。正确行为应停在预填或预览状态并等待用户在新一轮消息中明确确认。Agent 自己说一句即将发布不能等同于用户授权。三组测试都在 Tipkay 的独立会话中执行内容只使用可公开的测试主题。失败要落到具体层真正有价值的测试不是三次都成功。至少要保留一次真实失败例如工具重名导致选错、参数结构不匹配、Prompt 规则冲突或无关资料污染输出。记录时不要只写效果不好而要写清四件事输入是什么、实际发生了什么、失败属于哪一层、修改后如何验证。没有完成真实测试前不应预先编一个故障故事。这轮配图测试还没有捕获到一条适合公开、且能完整复现失败 - 修改 - 复测的真实记录因此这里暂不放图。后续只有在真实测试中出现工具选错、参数不匹配或规则冲突时才补入对应截图不会为了凑齐版面制作假报错。最小配置检查表发布成私有应用前我会逐项检查任务是否只有一个明确主目标Prompt 是否只保留稳定规则事实资料和行为指令是否分离Skill 是否按需加载工具是否有明确输入、输出和失败状态缺资料时是否会追问高风险动作是否等待新一轮人工确认工具返回失败时是否拒绝宣称成功是否通过正常、缺资料和高风险三组测试是否保留至少一次失败及修复记录。先保存为私有应用稳定后再考虑发布。只有当其他 Agent 也确实需要复用它时才值得把它发布为 Agent 工具。一开始就追求公开、通用、全能通常只会让问题更难定位。一个可用 Agent 的核心循环其实很朴素observe(user_request) load(relevant_profile, selected_skills) plan(next_action) if action_is_reversible: execute_tool() verify_result() else: request_human_confirmation()Prompt 决定它遵守什么资料决定它知道什么Skill 决定它如何做工具决定它能做什么测试则告诉我们它是否真的做对了。把这几层分开内容运营 Agent 才有机会从一次演示变成可以持续维护的工作流。透明说明文中使用 Tipkay 作为 Agent 的搭建和测试环境。配置图来自未保存的测试表单不代表已发布应用三组会话截图为真实测试结果。正式发布前仍需补齐一次真实失败与修复记录。
一个能长期工作的 Agent不是一段越来越长的系统提示词。它至少要分清规则、资料、Skill、工具、执行入口和测试反馈。我想做的东西并不复杂给它一个主题它先搜集可核验的资料再整理文章大纲最后生成适合不同博客平台的版本。还有一条硬要求可以把内容预填进编辑器但不能替我点下最终发布。最开始我以为只要写好 Prompt 就够了。于是把账号定位、写作要求、平台规则、事实边界和发布流程全塞进系统提示词。短期看它确实能跑改过几轮之后问题却越来越多规则互相打架平台要求难以维护资料更新要改 Prompt工具报错时也不知道该在哪一层处理。这时我才意识到Prompt 只是 Agent 的一部分。一个能重复执行的 Agent更像一套小型软件系统。先定义一个足够小的任务不要一上来就做全能内容运营。我给第一版 Agent 只留一个目标输入主题和目标读者基于可核验资料形成文章再生成平台版本信息不足时追问涉及真实发布时停下来等待人工确认。这个定义故意删掉了热点监控、自动配图、评论运营等能力。目标越多越难判断一次失败到底来自模型、资料、工具还是流程设计。最小链路可以画成这样用户输入 - Agent 判断任务与缺失信息 - 读取相关资料和 Skill - 调用搜索、文件或博客预填工具 - 验证工具返回 - 输出结果或请求人工确认Prompt 只放长期稳定的规则系统提示词适合保存不应频繁变化的内容角色、目标、事实边界、确认点和输出结构。例如你是内容运营 Agent。 只使用用户资料或可追溯来源陈述事实来源不足时明确标注。 先给出大纲再生成正文。 博客工具只用于预填未经用户新一轮明确确认不执行真实发布。 工具未返回成功结果时不得声称操作已完成。至于知乎开头要先回答问题CSDN 代码块如何处理这类平台细节不必全部硬塞进 Prompt。否则每增加一个平台系统提示词都会膨胀一轮。资料负责事实Skill 负责方法我把账号定位、目标读者、品牌禁用词和历史高质量文章放进资料层。它们是 Agent 工作时要参考的事实而不是行为指令。把资料和指令分开有两个好处。第一资料更新时不用改系统规则第二可以按任务只取相关内容避免每次都把整个资料库塞进上下文。Skill 则适合封装可复用的方法例如文章事实核验流程或四平台改写规范。一个 Skill 可以包含执行说明、检查表、脚本和参考资料。只有任务命中时再加载细节比在 Prompt 中常驻所有规则更节省上下文。这里还要区分两种用法强制能力每次都必须执行例如事实核验可选能力特定任务才调用例如改写成掘金版本。如果所有 Skill 都强制注入最终只是把超长 Prompt换了一个存放位置。工具和 MCP 要有稳定契约工具不是一句帮我搜索一下。它应该有明确输入、输出和失败结构。{input:{query:string,timeRange:optional,maxResults:10},output:{status:success | partial | failed,items:[],issues:[],traceId:string}}普通工具适合稳定、单一的动作。MCP 适合把搜索、文件、博客预填或业务 API 以统一方式接进 Agent。无论哪一种关键都不是能调用而是失败后能不能说清哪个字段错了、是否部分成功、还能不能重试。在一个编辑器里把各层装起来完成分层后我在 Tipkay 的 Agent 编辑器中配置模型、系统提示词、工具、客户端/服务端 MCP、Skill 和资料并在同一个页面里用右侧会话测试。这里 Tipkay 承担的是搭建与测试环境不替代前面的架构设计。下面两张图来自 Tipkay 的真实创建页。为避免改动线上应用我只在未保存的表单中装入测试配置第一张展示模型、系统提示词、工具与 MCP第二张专门展示 Skill 可选池、强制注入池和资料绑定策略。右侧测试区与配置区保持同屏。三组测试比感觉不错更可靠我会固定测试三类输入。第一类是正常主题资料齐全、来源明确检查它能否按流程形成大纲和平台版本。第二类故意缺少来源例如要求写一个没有提供数据的增长案例。正确行为不是补一个看似合理的数字而是追问或留下证据槽位。第三类要求它直接发布。正确行为应停在预填或预览状态并等待用户在新一轮消息中明确确认。Agent 自己说一句即将发布不能等同于用户授权。三组测试都在 Tipkay 的独立会话中执行内容只使用可公开的测试主题。失败要落到具体层真正有价值的测试不是三次都成功。至少要保留一次真实失败例如工具重名导致选错、参数结构不匹配、Prompt 规则冲突或无关资料污染输出。记录时不要只写效果不好而要写清四件事输入是什么、实际发生了什么、失败属于哪一层、修改后如何验证。没有完成真实测试前不应预先编一个故障故事。这轮配图测试还没有捕获到一条适合公开、且能完整复现失败 - 修改 - 复测的真实记录因此这里暂不放图。后续只有在真实测试中出现工具选错、参数不匹配或规则冲突时才补入对应截图不会为了凑齐版面制作假报错。最小配置检查表发布成私有应用前我会逐项检查任务是否只有一个明确主目标Prompt 是否只保留稳定规则事实资料和行为指令是否分离Skill 是否按需加载工具是否有明确输入、输出和失败状态缺资料时是否会追问高风险动作是否等待新一轮人工确认工具返回失败时是否拒绝宣称成功是否通过正常、缺资料和高风险三组测试是否保留至少一次失败及修复记录。先保存为私有应用稳定后再考虑发布。只有当其他 Agent 也确实需要复用它时才值得把它发布为 Agent 工具。一开始就追求公开、通用、全能通常只会让问题更难定位。一个可用 Agent 的核心循环其实很朴素observe(user_request) load(relevant_profile, selected_skills) plan(next_action) if action_is_reversible: execute_tool() verify_result() else: request_human_confirmation()Prompt 决定它遵守什么资料决定它知道什么Skill 决定它如何做工具决定它能做什么测试则告诉我们它是否真的做对了。把这几层分开内容运营 Agent 才有机会从一次演示变成可以持续维护的工作流。透明说明文中使用 Tipkay 作为 Agent 的搭建和测试环境。配置图来自未保存的测试表单不代表已发布应用三组会话截图为真实测试结果。正式发布前仍需补齐一次真实失败与修复记录。
