pstack 深度解读：如何把 AI 规则变成 Agent 的工程护栏

来源：三少科技视频《pstack 深度解读：你的 agent，最值得抄的一套 AI 规则》，页面显示发布于 2026 年 10 月 19 日。当前可访问页面只提供标题、频道和封面；视频字幕、描述正文无法获取。下文是围绕视频主题整理的工程导读与实践建议，不是逐字稿，也不把无法核实的内容归为视频原话。

“给 Agent 一套规则”听起来像写几段提示词，真正落到代码仓库后却是一个工程问题：规则放在哪里、什么时候生效、能否验证、出错时如何恢复。值得借鉴的不是规则写得有多长，而是它能不能稳定地改变 Agent 的行为，并且让人看得见这种改变。

本文从 pstack 这个视频主题出发，整理一套评估 AI 规则的通用方法。由于字幕不可用，具体规则文件、目录结构及演示步骤均不作视频内容复述；涉及项目本身的实现细节，应以原视频或项目文档为准。

规则不是一份更长的提示词

面向 Agent 的规则至少需要回答四个问题：

问题	规则要说明什么	可检查的结果
目标是什么	任务要交付的行为或产物	完成条件清楚且可观察
上下文在哪里	仓库结构、命令、模块职责	Agent 能定位相关资料
边界是什么	禁止动作、权限范围、外部副作用	高风险行为有明确控制点
如何验收	检查命令、预期结果、证据	人能判断任务是否完成

如果规则只有“认真修改”“保持高质量”这类要求，执行者很难据此做出一致决定。好的规则会把判断变成动作，例如“修改 API 后运行对应单元检查，并在最终报告中列出命令和结果”。

从仓库约定开始，而不是一次写完

Agent 的工作环境会变：目录、脚本、部署流程、测试工具都会更新。因此规则最好从当前代码库里能够验证的事实出发，并分清稳定约束和易变信息。

一个轻量的落地顺序是：

1. 写清项目入口、重要目录和本地开发命令。
2. 标明哪些目录或数据有特殊约束，例如生成文件、迁移记录或用户内容。
3. 描述常见任务的完成条件和对应检查。
4. 把范围较窄的工作约定放到对应子目录，避免每个任务都加载整本手册。
5. 在真实任务中观察误用，再补充最小一条能够避免复发的规则。

每一条规则都应该有维护理由。若一条说明既不影响执行选择，也不能帮助定位或验收问题，它可能只是额外上下文成本。

让规则能被执行和验证

规则的质量不应只靠阅读体验来判断。可以用一个小型评估集：选取几类常见任务，记录 Agent 是否找对文件、是否遵守边界、是否运行适当检查，以及报告有没有给出证据。每次调整规则后，使用同一批任务对比结果。

重点观察四类失败：

• 遗漏：忘记必要步骤，例如没有运行针对性验证。
• 过度执行：规则模糊导致修改了任务范围之外的文件。
• 错误确信：只看最终输出，没确认中间调用和结果。
• 上下文噪声：相互重复或过时的规则让真正约束被淹没。

遇到失败时，先确认原因是信息缺失、工具能力不足、权限过宽，还是验收标准不明确。修复原因比不断追加“务必小心”更有效。对高风险动作，应设计确认或审批点，而不是寄希望于模型每次都正确理解措辞。

规则要进入一个可恢复的工作流

Agent 规则和工作流应当一起设计：开始前识别目标与边界，执行中留下变更和验证证据，失败后能定位并回到安全状态。比如修改代码时，至少应能追溯改动文件、测试输出和提交内容；处理外部系统时，还要明确哪些动作会产生真实副作用。

一条实用的任务闭环可以写成：

读取项目约定
  → 定位与目标直接相关的文件
  → 小范围修改
  → 运行对应检查并查看差异
  → 汇报结果、证据和未解决问题

这比单独追求“让 Agent 一次写对”更可靠。规则提供决策约束，工具提供执行能力，验证给出证据，人工负责设置风险边界；它们共同构成 Agent 的实际运行环境。

用 GPT88 统一模型接口做模型对照

如果要评估同一套规则在不同模型上的表现，可以把模型调用和规则集分开：提示、工具权限及测试任务保持一致，仅替换当前账户可用的模型 ID。GPT88 提供 OpenAI 兼容的接口，客户端可使用同一 base_url，具体模型应先通过模型列表确认，不要在规则文件中写死可能变化的名称。

curl https://api.gpt88.cc/v1/chat/completions \
  -H "Authorization: Bearer $GPT88_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<从 GET /v1/models 选择的模型 ID>",
    "messages": [
      {"role": "system", "content": "按仓库中的 Agent 规则执行任务。"},
      {"role": "user", "content": "请审查当前改动，并列出发现及依据。"}
    ]
  }'

模型对照要固定任务、输入和评分方式，并记录失败类别与工具轨迹。单次回答的风格差异不能说明规则更有效；应比较重复任务中的完成率、越界率、验证覆盖和人工返工量。模型是否支持特定工具调用行为，也要在当前接口和模型能力下实测。

落地检查表

• 规则针对真实任务，且每条都能影响执行选择。
• 项目事实有对应文件、脚本或命令作为依据。
• 权限、不可触碰范围和有副作用的操作写清楚。
• 完成条件包含可运行的检查或可观察证据。
• 规则有负责人或更新方式，过时内容会被删除。
• 用固定任务集评估规则变更，而不是只比较措辞。
• 失败时能够停止、检查状态并恢复。

评估一套 Agent 规则，可以从一个具体问题开始：它是否让系统在任务失败或输入异常时更容易被理解、检查和恢复？如果答案是否定的，就继续缩小规则目标，补上证据和边界，再用真实任务验证。

想进一步了解规则之外的运行时组成，可阅读Harness 的五个组件，了解指令、工具、约束、状态与编排如何共同决定 Agent 的可靠性。