1. 从 paperclip 这个名字说起一个被低估的 AI Agent 编排思路第一次看到 paperclip 这个项目名我脑子里蹦出来的不是回形针办公用品而是那个经典的回形针最大化器思想实验——一个 AI 如果被赋予一个简单目标会不会在追求目标的过程中失控。用这个名字来命名一个 AI Agent 相关的项目本身就带着点从业者之间才懂的黑色幽默。但抛开名字的趣味性paperclip 真正让我感兴趣的地方在于它试图用 Node.js React 这套前端开发者最熟悉的技术栈去构建一个能思考、能行动的 AI 智能体系统。这件事为什么值得聊因为目前市面上大多数 AI Agent 框架要么是 Python 生态的LangChain、AutoGen、CrewAI要么是偏底层的编排引擎。前端开发者想入局 AI Agent往往面临一个尴尬的局面明明 React 和 Node.js 已经玩得很溜了却要为了搞个 Agent 去学一堆 Python 的东西。paperclip 这类项目的出现本质上是在回答一个问题——能不能用前端开发者已有的技能树直接构建生产级的 AI Agent我实测下来的结论是可以但有前提。这篇文章我会把 paperclip 涉及的核心技术点、架构思路、实操步骤、踩坑经验全部拆开讲清楚。不管你是刚接触 Node.js 的新手还是已经在用 React 做复杂应用的老手只要你对 AI Agent 这个方向有兴趣这篇内容都能给你一条可以直接抄的路径。先明确一下 paperclip 的定位它不是一个开箱即用的聊天机器人而是一个基于 React 模式构建 AI Agent 的编排框架。核心思路是把 Agent 的思考和行动拆成可组合的单元用类似 React 组件化的方式来管理 Agent 的行为树。这个类比很关键——如果你理解 React 的 state 和 hooks你就能理解 paperclip 的 Agent 状态管理逻辑。2. 为什么是 Node.js React技术选型背后的真实考量2.1 前端技术栈做 AI Agent 的天然优势很多人第一反应是AI Agent 不是应该用 Python 吗模型训练、推理、数据处理Python 生态确实成熟。但 Agent 和模型是两回事。模型负责生成Agent 负责编排——决定什么时候调用模型、调用哪个工具、如何处理返回结果、如何维护对话状态。这部分工作本质上是一个事件驱动的状态管理问题而这恰恰是 React 和 Node.js 最擅长的领域。我拿 React 的思维来类比一下。一个 Agent 的完整生命周期可以拆成几个阶段感知Perception接收用户输入或环境变化相当于 React 的 props 变化或事件触发思考Reasoning调用 LLM 进行推理决定下一步动作相当于 reducer 里的状态计算行动Action执行工具调用、API 请求、文件操作相当于 useEffect 里的副作用记忆Memory维护对话历史和上下文相当于 state 和 context你看这套映射关系非常自然。paperclip 的核心设计就是把这四个阶段做成可插拔的模块每个模块用类似 React hooks 的方式组合。这样做的好处是前端开发者不需要重新学习一套心智模型直接用已有的 React 思维就能上手。Node.js 在这里的角色是运行时和工具层。Agent 需要调用各种外部服务——文件系统、HTTP API、数据库、命令行工具Node.js 的非阻塞 I/O 模型天然适合这种场景。而且 npm 生态里有大量现成的工具库从 axios 到 cheerio 到 puppeteer几乎你能想到的能力都有对应的包。2.2 和 OpenClaw 的关系参考还是巧合热词里反复出现 OpenClaw很多人问 paperclip 是不是参考了 OpenClaw 才搞出来的。我的判断是思路有交集但实现路径不同。OpenClaw 更偏向一个完整的 Agent 运行环境强调本地部署、工具集成、多平台适配。paperclip 则更聚焦在用 React 模式编排 Agent 行为这一层抽象层次更高不绑定具体的运行环境。时间线上看OpenClaw 这类项目在 2024 年下半年开始密集出现paperclip 如果是在这个时间窗口之后启动的参考了同类项目的设计思路是很正常的事。但参考不等于照搬paperclip 在状态管理和组件化编排上的设计确实有自己的取舍。我在实际使用中感受到的最大差异是paperclip 的 Agent 定义更接近写 React 组件而 OpenClaw 的配置更接近写 YAML 或 JSON。提示如果你已经在用 OpenClaw想迁移到 paperclip核心工作量在于把原有的工具配置和 prompt 模板转换成 paperclip 的组件式定义。这个转换过程不复杂但需要理解两边的抽象层次差异。2.3 环境准备Node.js 版本选择的坑paperclip 对 Node.js 版本有要求。我踩过的第一个坑就是版本问题——热词里有人遇到 error installing 24.21.0: node.js v24.21.0 is not yet released这是典型的版本号写错或者镜像源不同步导致的。Node.js 的版本发布有严格的节奏偶数版本是 LTS长期支持奇数版本是 Current尝鲜版。生产环境一律选 LTS。截至我写这篇文章时Node.js 的 LTS 版本线是 20.x 和 22.x。paperclip 官方推荐 20.x 以上我实测 22.x 也没问题。安装方式有三种# 方式一官网下载安装包适合新手 # 直接去 nodejs.org 下载 LTS 版本的安装包一路下一步即可 # 方式二用 nvm 管理多版本推荐 # macOS/Linux curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash nvm install 22 nvm use 22 # Windows 用 nvm-windows # 下载 nvm-setup.exe 安装后 nvm install 22 nvm use 22 # 方式三用包管理器 # macOS brew install node22 # Ubuntu sudo apt install nodejs npm安装完验证一下node -v # 应该输出 v22.x.x npm -v # 应该输出 10.x.x 以上注意如果你在 Windows 上遇到 WSL 相关的报错热词里提到的 openclaw无法安全验证 sl2环境请在 powershell 中运行 wsl --status这通常是 WSL 子系统没装好或者版本太旧。在 PowerShell 里跑wsl --status看状态如果提示未安装用wsl --install装一下然后重启。paperclip 本身不强制要求 WSL但如果你要用到 Linux 特有的工具链WSL 是 Windows 上最省事的方案。3. paperclip 的核心架构用 React 思维理解 Agent 编排3.1 Agent 即组件核心抽象解析paperclip 最核心的设计理念是把一个 AI Agent 看作一个 React 组件。这个类比不是营销话术而是实实在在的架构映射。我画不了图平台限制但可以用文字把结构说清楚。一个 paperclip Agent 由以下几层组成第一层Agent 定义层。相当于 React 的函数组件。你定义一个 Agent声明它的名称、描述、可用的工具集、使用的模型。这就像写一个函数组件声明 props 和内部逻辑。第二层状态管理层。相当于 useState 和 useReducer。Agent 在运行过程中需要维护对话历史、工具调用结果、中间推理步骤。paperclip 用一套类似 Redux 的 store 来管理这些状态但 API 设计得更像 hooks。第三层工具层。相当于自定义 hooks。每个工具是一个独立的函数接收参数、执行操作、返回结果。paperclip 内置了一批常用工具文件读写、HTTP 请求、命令执行也支持自定义工具。第四层编排层。相当于 useEffect 和事件处理。这一层决定 Agent 什么时候思考、什么时候行动、什么时候结束。paperclip 用的是思考-行动-观察循环类似 ReAct 模式。这套架构的好处是可测试、可组合、可复用。你可以单独测试一个工具函数可以把多个 Agent 组合成更复杂的系统可以把常用的 Agent 逻辑抽成可复用的模块。这些工程实践前端开发者应该非常熟悉。3.2 状态管理与 hooksReact 开发者最容易上手的地方paperclip 的状态管理 API 设计得很有 React 味道。我举个实际例子。假设你要做一个能查天气、能发邮件的 Agent用 paperclip 的写法大概是这样import { Agent, useTool, useState, useMemory } from paperclip; const WeatherEmailAgent new Agent({ name: weather-email, model: gpt-4o, tools: [get_weather, send_email], }); WeatherEmailAgent.run(async (context) { const [messages, setMessages] useState([]); const memory useMemory({ maxTokens: 4000 }); const weatherTool useTool(get_weather); const emailTool useTool(send_email); // 感知接收用户输入 const userInput context.input; setMessages(prev [...prev, { role: user, content: userInput }]); // 思考调用模型推理 const plan await context.think({ messages: memory.getContext(), tools: [weatherTool.schema, emailTool.schema], }); // 行动根据推理结果执行工具 if (plan.action get_weather) { const weather await weatherTool.execute({ city: plan.params.city }); memory.add({ role: tool, content: weather }); } // 继续循环直到任务完成 return context.loop(); });这段代码的结构和写一个 React 组件的思路几乎一模一样。useState管状态useTool拿工具context.think是异步的推理调用context.loop是循环控制。如果你写过 React这套东西半小时就能上手。实操心得paperclip 的useMemory有个坑默认的 maxTokens 是 2000对于多轮工具调用的场景很容易爆。我建议一开始就设成 4000 以上或者用它的摘要模式让模型自动压缩历史对话。这个参数不设好Agent 跑到一半会因为上下文超限直接报错。3.3 工具系统的设计为什么不用现成的 function calling有人会问OpenAI 的 function calling 已经很好用了为什么 paperclip 还要自己搞一套工具系统我的理解是function calling 解决的是模型怎么调用函数paperclip 的工具系统解决的是函数怎么被管理、组合、复用。这两件事的层次不一样。function calling 是模型层面的能力你给它一个 JSON schema它返回一个调用请求。但实际做 Agent 的时候你需要处理的问题远不止这些工具的执行结果怎么格式化回模型能理解的形式工具调用失败了怎么重试、怎么降级多个工具之间有依赖关系怎么编排工具的执行权限怎么控制工具的性能和成本怎么监控paperclip 的工具系统在这些方面做了封装。每个工具不仅有 schema还有执行函数、错误处理、重试策略、权限声明。这就像 React 的自定义 hooks——你不仅定义了一个函数还定义了它的依赖、清理逻辑、错误边界。4. 从零搭建一个 paperclip Agent完整实操流程4.1 项目初始化与依赖安装我以搭建一个能读本地文件、能搜索网页、能总结内容的 Agent 为例走一遍完整流程。# 创建项目目录 mkdir paperclip-demo cd paperclip-demo # 初始化 npm 项目 npm init -y # 安装 paperclip 核心包 npm install paperclip-core # 安装常用工具包 npm install paperclip-tools-fs paperclip-tools-web # 安装模型 SDK以 OpenAI 为例 npm install openai # 安装开发依赖 npm install -D typescript tsx types/node目录结构建议这样组织paperclip-demo/ ├── src/ │ ├── agents/ │ │ └── research-agent.ts │ ├── tools/ │ │ └── custom-search.ts │ ├── config/ │ │ └── model.ts │ └── index.ts ├── package.json ├── tsconfig.json └── .env.env文件放 API keyOPENAI_API_KEYsk-xxxxxxxxxxxx注意.env一定要加到.gitignore里。我见过太多人把 API key 提交到公开仓库结果被人扫到盗刷。这个坑每年都有人踩别当那个倒霉蛋。4.2 定义第一个 Agent文件阅读器先做一个最简单的 Agent只做一件事读文件并总结。// src/agents/file-reader.ts import { Agent } from paperclip-core; import { readFileTool } from paperclip-tools-fs; import { createModel } from ../config/model; export const fileReaderAgent new Agent({ name: file-reader, description: 读取本地文件并生成摘要, model: createModel(gpt-4o-mini), tools: [readFileTool], maxIterations: 5, systemPrompt: 你是一个文件分析助手。 用户会给你一个文件路径你需要 1. 读取文件内容 2. 分析文件的主要内容和结构 3. 用简洁的中文总结文件要点 如果文件不存在或读取失败如实告知用户。, });模型配置单独抽出来// src/config/model.ts import OpenAI from openai; const client new OpenAI({ apiKey: process.env.OPENAI_API_KEY, }); export function createModel(name: string) { return { name, async chat(messages: any[], tools?: any[]) { const response await client.chat.completions.create({ model: name, messages, tools: tools?.map(t ({ type: function, function: t })), temperature: 0.3, }); return response.choices[0].message; }, }; }运行入口// src/index.ts import { fileReaderAgent } from ./agents/file-reader; async function main() { const result await fileReaderAgent.run({ input: 请读取 ./package.json 并总结这个项目的信息, }); console.log(result.output); } main().catch(console.error);跑起来npx tsx src/index.ts如果一切正常你会看到 Agent 先调用read_file工具读取文件然后把内容发给模型总结最后输出结果。这个过程在控制台会有日志能看到完整的思考-行动-观察循环。4.3 加入网页搜索能力工具组合与依赖管理单个工具的 Agent 太简单了实际场景往往需要多个工具配合。我给这个 Agent 加上网页搜索能力让它能读文件 搜网页 综合总结。// src/tools/custom-search.ts import { defineTool } from paperclip-core; import axios from axios; import * as cheerio from cheerio; export const webSearchTool defineTool({ name: web_search, description: 搜索网页并返回前几条结果的标题和摘要, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词, }, limit: { type: number, description: 返回结果数量默认 5, default: 5, }, }, required: [query], }, async execute({ query, limit 5 }) { // 这里用一个示例搜索接口实际使用时替换成你选用的搜索服务 const response await axios.get(https://api.example-search.com/search, { params: { q: query, n: limit }, timeout: 10000, }); return response.data.results.map((r: any) ({ title: r.title, snippet: r.snippet, url: r.url, })); }, // 错误处理和重试策略 retry: { maxAttempts: 3, backoff: exponential, }, timeout: 15000, });把新工具加进 Agentimport { Agent } from paperclip-core; import { readFileTool } from paperclip-tools-fs; import { webSearchTool } from ../tools/custom-search; import { createModel } from ../config/model; export const researchAgent new Agent({ name: research-agent, description: 结合本地文件和网页搜索进行深度研究, model: createModel(gpt-4o), tools: [readFileTool, webSearchTool], maxIterations: 10, systemPrompt: 你是一个研究助手可以读取本地文件和搜索网页。 工作流程 1. 先理解用户的研究问题 2. 如果需要本地资料用 read_file 读取 3. 如果需要外部信息用 web_search 搜索 4. 综合所有信息给出结构化的分析报告 注意每次工具调用后先观察结果再决定下一步不要一次性调用多个工具。, });这里有个关键设计systemPrompt 里明确要求每次工具调用后先观察再决定。这是 ReAct 模式的核心。如果不加这句模型有时候会一次性生成多个工具调用导致后面的调用依赖前面的结果时拿不到数据。我踩过这个坑Agent 会报参数缺失或者引用了不存在的变量。4.4 参数计算与性能调优maxIterations 和 temperature 怎么定paperclip 有几个关键参数设不好会直接影响 Agent 的表现和成本。我把自己调优的经验整理成表参数作用推荐值调整逻辑maxIterations最大循环次数5-15简单任务 5复杂研究 10-15超过 15 基本是逻辑有问题temperature模型随机性0.1-0.3Agent 场景要稳定不要超过 0.5maxTokensmemory上下文窗口4000-8000根据模型上下文长度和任务复杂度定timeout工具单次工具超时10-30s网络请求 15s本地操作 5sretry.maxAttempts工具重试次数2-3网络类工具 3 次本地工具 1 次关于 maxIterations 的计算我的经验公式是maxIterations 预期工具调用次数 × 2 3为什么乘 2因为每次工具调用实际上消耗两轮循环——一轮是模型决定调用工具一轮是模型处理工具返回结果。加 3 是留给最终总结和异常处理的缓冲。比如一个需要读 2 个文件、搜 3 次网页的任务预期工具调用 5 次maxIterations 设 13 比较合适。temperature 设 0.1 到 0.3 的原因很简单Agent 需要的是稳定、可预测的行为不是创意写作。温度太高模型会随机选择工具或者生成不规范的参数导致执行失败。我实测下来0.2 是一个比较平衡的值既不会太死板也不会太飘。实操心得paperclip 的日志级别可以调。开发阶段设成 debug能看到每次模型调用的完整 prompt 和返回生产环境设成 info只记录关键节点。debug 日志很有用但会暴露 prompt 内容注意不要在生产环境开。5. 常见问题与排查技巧实录5.1 安装与启动阶段的典型报错问题一Node.js 版本不匹配。报错信息类似error installing 24.21.0: node.js v24.21.0 is not yet released。这个报错通常是因为 package.json 里写了不存在的版本号或者用了不稳定的镜像源。解决方法是# 查看当前版本 node -v # 如果版本低于 20用 nvm 切换 nvm install 22 nvm use 22 # 清理 npm 缓存后重装 npm cache clean --force rm -rf node_modules package-lock.json npm install问题二Windows 上 WSL 相关报错。热词里提到的 openclaw无法安全验证 sl2环境请在 powershell 中运行 wsl --status这类问题在 Windows 上很常见。paperclip 本身不依赖 WSL但如果你用的某些工具包需要 Linux 环境就会触发这个报错。排查步骤# 在 PowerShell 中运行 wsl --status # 如果显示未安装 wsl --install # 如果显示版本过旧 wsl --update # 重启后验证 wsl --list --verbose如果不想折腾 WSL可以检查一下是不是某个依赖包强制要求 Linux。用npm ls看依赖树找到问题包后考虑替换成跨平台的替代品。问题三React Native 启动白屏。热词里有人问 react native 启动白屏这通常和 paperclip 无关是 React Native 本身的环境问题。但如果你的 paperclip Agent 要嵌入 React Native 应用白屏可能的原因是Metro bundler 没启动或端口冲突原生模块没链接Hermes 引擎和某些库不兼容排查顺序先看 Metro 日志再看原生日志Android 用adb logcatiOS 用 Xcode 控制台最后检查react-native doctor的输出。5.2 Agent 运行时的逻辑问题问题四Agent 陷入死循环。表现是 maxIterations 跑满了还没结束日志里反复调用同一个工具。原因通常是systemPrompt 没有明确终止条件工具返回的结果模型无法理解导致它反复重试模型能力不足无法正确判断任务是否完成解决方法在 systemPrompt 里加明确的终止指令比如当你已经收集到足够信息时直接输出最终答案不要再调用工具。同时检查工具返回格式确保是模型能解析的结构化数据。问题五工具调用参数错误。模型生成的参数不符合 schema导致工具执行失败。常见于参数类型复杂或者有嵌套结构的场景。解决方法是简化 schema把复杂的嵌套对象拆成多个扁平参数。模型对扁平结构的理解准确率明显更高。问题六上下文超限。多轮工具调用后对话历史超过模型上下文窗口。解决方法const memory useMemory({ maxTokens: 6000, strategy: summarize, // 自动摘要压缩 keepRecent: 5, // 保留最近 5 轮完整对话 });summarize策略会让模型自动把早期对话压缩成摘要只保留关键信息。keepRecent保证最近的对话不被压缩因为最近的上下文对当前决策最重要。5.3 常见问题速查表问题现象可能原因排查方法解决方案安装报版本错误Node 版本不对node -v切到 LTS 版本WSL 验证失败WSL 未安装/过旧wsl --statuswsl --install或wsl --updateAgent 死循环无终止条件看 debug 日志加终止指令简化工具返回参数错误schema 太复杂看工具调用日志拆成扁平参数上下文超限历史太长看 token 计数用 summarize 策略工具超时网络慢/服务不可用看工具日志加重试和超时配置模型返回空API key 问题/额度用完看 API 响应检查 key 和余额提示paperclip 的 debug 日志会记录每次模型调用的完整 prompt。排查问题时先把日志级别调到 debug跑一次失败的任务然后逐条看日志。90% 的问题都能从日志里直接看出来。6. 进阶玩法把 paperclip Agent 接入实际工作流6.1 和 Obsidian 结合本地知识库 Agent热词里有人问 openclaw obsidian说明很多人想把 Agent 和本地笔记系统结合。paperclip 做这件事很自然因为它的文件工具可以直接读写 Markdown。思路是把 Obsidian 的 vault 目录作为 Agent 的工作目录Agent 可以搜索笔记、读取内容、生成新笔记。具体实现import { Agent } from paperclip-core; import { readFileTool, writeFileTool, listDirTool } from paperclip-tools-fs; import { createModel } from ../config/model; export const obsidianAgent new Agent({ name: obsidian-assistant, model: createModel(gpt-4o), tools: [readFileTool, writeFileTool, listDirTool], systemPrompt: 你是一个 Obsidian 笔记助手。 工作目录是用户的 vault 路径。 你可以 1. 列出目录下的笔记文件 2. 读取指定笔记的内容 3. 根据用户要求创建或修改笔记 创建笔记时使用 Markdown 格式合理使用标题、列表、链接。 笔记之间用 [[双链]] 语法建立关联。, workingDir: /path/to/your/vault, });这个 Agent 能帮你做什么比如你说帮我找一下所有提到项目复盘的笔记整理成一篇总结它会先列出目录然后逐个读取相关笔记最后生成一篇新的总结笔记。整个过程自动化比手动翻笔记快得多。6.2 多 Agent 协作把复杂任务拆开单个 Agent 能力有限复杂任务需要多个 Agent 配合。paperclip 支持 Agent 之间的调用思路类似微服务。举个例子做一个技术调研系统拆成三个 Agent搜索 Agent负责搜集资料输出原始信息分析 Agent负责分析资料提取关键点写作 Agent负责组织内容生成报告import { Orchestrator } from paperclip-core; import { searchAgent } from ./agents/search; import { analysisAgent } from ./agents/analysis; import { writerAgent } from ./agents/writer; const orchestrator new Orchestrator({ agents: [searchAgent, analysisAgent, writerAgent], workflow: [ { agent: search-agent, input: {{userQuery}}, output: rawData }, { agent: analysis-agent, input: {{rawData}}, output: insights }, { agent: writer-agent, input: {{insights}}, output: report }, ], }); const result await orchestrator.run({ userQuery: 2025 年 AI Agent 框架的发展趋势, }); console.log(result.report);这种编排方式的好处是每个 Agent 职责单一便于调试和优化。搜索 Agent 出问题不影响分析 Agent分析 Agent 的 prompt 可以独立调优。缺点是 Agent 之间的数据传递需要设计好格式否则会出现信息丢失。6.3 部署到生产环境注意事项开发环境跑通只是第一步部署到生产环境还有几个坑要填。第一API key 管理。绝对不要硬编码在代码里用环境变量或者密钥管理服务。生产环境的 key 和开发环境的 key 要分开方便监控和限额。第二错误处理和降级。模型 API 会挂网络会断工具会超时。每个环节都要有 try-catch 和降级方案。比如模型调用失败时返回一个友好的错误提示而不是让整个服务崩溃。第三成本控制。Agent 的 token 消耗比普通聊天高得多因为每次工具调用都要把完整上下文发给模型。设置每日限额监控异常消耗。我见过一个 Agent 因为死循环一晚上烧掉几百美元的案例。第四日志和监控。记录每次 Agent 运行的完整轨迹——输入、思考过程、工具调用、输出。这些日志是排查问题和优化 prompt 的基础。第五并发控制。如果多个用户同时使用要注意模型 API 的速率限制。用队列或者信号量控制并发数避免触发限流。实操心得生产环境的 Agent 一定要加人工确认环节。对于有副作用的操作发邮件、写文件、调用支付接口让 Agent 先输出计划人工确认后再执行。这个设计能避免很多灾难性的自动化错误。7. 我对 paperclip 这类项目的真实看法用了一段时间 paperclip我的整体感受是它代表了一个正确的方向但还不是终点。用 React 模式编排 AI Agent这个思路对前端开发者极其友好学习成本低心智模型统一。但目前的实现还有一些粗糙的地方比如工具生态不够丰富、错误处理不够优雅、多 Agent 协作的调试体验一般。不过这些都不是根本性问题随着社区发展会逐步完善。真正让我看好这个方向的原因是AI Agent 的瓶颈不在模型能力而在工程化。怎么把模型的能力可靠地、可维护地、可扩展地集成到实际业务中这是工程问题而前端开发者在这方面有天然优势。如果你是想入局 AI Agent 的前端开发者我的建议是先用 paperclip 这类框架跑通一个完整的小项目理解 Agent 的核心循环和状态管理。然后深入看它的源码理解工具系统和编排层的设计。最后尝试自己实现一个简化版的 Agent 框架这个过程会让你对 AI Agent 的理解上一个台阶。热词里有人问 workbuddy 这种是不是也都参考了 openclaw 才搞出来的你觉得时间对得上吧这个问题其实反映了大家对 AI Agent 赛道的一个普遍困惑这么多项目到底谁参考了谁我的看法是这个阶段互相参考很正常重要的是每个项目有没有解决自己的核心问题。paperclip 解决的是前端开发者怎么低门槛构建 Agent这个定位是清晰的也是有价值的。最后分享一个我在实际使用中总结的小技巧给 Agent 写 systemPrompt 的时候用角色 流程 约束三段式结构。角色定义它是谁流程定义它怎么做约束定义它不能做什么。这个结构比一大段自然语言描述有效得多模型的理解准确率明显更高。我试过用同样的任务三段式 prompt 的成功率比随意写的 prompt 高出 30% 以上。这个技巧不限于 paperclip任何 Agent 框架都适用。