一个能长期工作的 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 的搭建和测试环境。配置图来自未保存的测试表单，不代表已发布应用；三组会话截图为真实测试结果。正式发布前仍需补齐一次真实失败与修复记录。