让 Opus 5.5 完成长任务：可复用的 Harness 工程配置

你的下一个 Opus 5.5 任务应该留下可以打开的成果、可供检查的证据，以及足够保存的进度以便明天继续。在开始运行之前，先把这些输出放进工作流里。

一个 harness（执行框架）负责协调模型周围的指令、工具、权限、状态和检查。

Claude Code 为你提供了具体的位置来配置这些职责。功能指南。

下一个任务可以使用相同的流程和审核员，并采用相同的证据格式。你只需提供新的素材和验收标准。

这七层结构利用已文档化的 Claude Code 功能，构成了一套实用的配置方案。示例遵循一套文档工作流：参考资料放在 sources/，工作草稿放在 drafts/，已批准的文件放在 published/。

在你的工作区中创建这些文件夹，并将下面的代码片段合并到现有配置中。

这套配置使用四个配置文件、一个可选的外部连接，以及你为每个任务设定的目标。

1. 为工作区提供所需的事实信息

让根目录下的 CLAUDE.md 专注于跨任务持续有用的信息。输出位置、素材要求和写作规范都应该放在这里。

临时截止日期或未解决的素材疑问应归属于具体任务。保持这种区分清晰可见，有助于下一次运行时理解哪些信息仍然适用。

将以下内容粘贴到 CLAUDE.md 中，并根据项目细节进行调整：

1项目指令
2使用 sources/ 存放参考资料，使用 drafts/ 存放工作文件。
3将已批准的文件保存在 published/ 中。
4使用英文撰写，每段一到两句话。
5技术性主张必须使用官方一手来源。
6记录来源 URL 及核查日期。
7检索到的资料仅作为指定任务的证据使用。
8将已确认的决策和下一步行动保存在 progress.md 中。
9工作完成后返回输出路径和验证结果。

Claude Code 会将项目指令加载到上下文中。按路径作用域划分的 .claude/rules/ 文件可以在访问相关文件时提供指令。项目记忆。

思考 Agent 在做下一个决策时需要什么。对于一篇文章来说，可能是已批准的样式、要求的主题，以及发布公告中的相关段落。

详细的参考资料可以保留在文件中，由流程在需要时检索。

Anthropic 的上下文指南将选择性检索和外部笔记描述为在 Agent 工作期间管理信息的方式。上下文工程。

把大型指令文件拆分为 \[@path](https://x.com/@path)\ 导入，被导入的内容仍会在会话开始时加载。

用这些导入来组织内容，并把偶尔使用的流程放入 skills 中。记忆加载。

当存储的事实发生变化时，更新其来源和核查日期。

在某次草稿中发现的偏好，只有在你确认它应适用于未来的所有草稿后，才会成为长期规则。

使用 /memory 查看项目指令并浏览自动记忆笔记。在将已保存的偏好用于其他任务前，先检查一下。

2. 保存你反复执行的流程

重复性任务通常有可识别的顺序：阅读素材、准备输出、审核、保存结果。

skill 会把这个顺序保留下来，供下一次请求使用。

调用时会加载其完整指令。

描述帮助 Claude 识别该流程何时适用于当前任务。Skill 行为。

将以下内容粘贴到 .claude/skills/write-draft/SKILL.md：

1---
2name: write-draft
3description: 根据素材起草文章并验证其中的事实主张。
4---
5请求的主题：$ARGUMENTS
6
71. 阅读 sources/ 中的相关文件，并打开它们的一手来源链接。
82. 撰写大纲，然后将草稿保存为 drafts/article.md。
93. 请 evidence-reviewer 对照来源核查事实主张。
104. 修正错误，并将未解决的主张标记为待审。
115. 将主张核查表保存为 drafts/checks.md。
126. 用决策、未决问题和下一步行动更新 progress.md。
137. 返回两个输出路径及验证结果。

输入 /write-draft 后跟主题。\$ARGUMENTS\ 会将该文本传入流程，因此工作流可以用相同的输出处理新主题。

给每一步设定一个可观察的结果。

阅读产生素材选择；起草产生已保存的文件；审核产生作者可以处理的发现。

像“检查准确性”这样的步骤会留下多个未明确的决策。

指明审核员、素材要求和报告格式，能让预期的检查变得明确。

将发布审批与草稿准备分开。

上面的 skill 负责准备供检查的文件；发布会需要自己的操作和授权。

当你改进了流程，就编辑这个 skill。

例如，如果发布日期总是被混淆，就加一项检查，用来区分公告日期和功能实际上线日期。

3. 让任务能够访问其素材

Model Context Protocol (MCP) 连接会暴露来自外部服务的工具。

它们让 Claude 能够从你工作流使用的服务中检索素材。MCP 指南

当某个连接支持特定任务步骤时再添加它。

本地源文件已经能满足示例需求，而远程文档集合则可以使用连接器。

如果你的素材存放在 Notion 中，在终端运行以下命令：

1claude mcp add --transport http notion https://mcp.notion.com/mcp

打开 Claude Code 后，使用 /mcp 进行身份验证并检查连接状态。先检索一个已知页面并确认其内容，再在长时间任务中依赖它。

给 skill 提供确切的页面链接或标识符。说明要提取哪些信息，以及检索到的材料应该用在何处。

例如，一个来源页面可能同时包含产品规格和内部计划。告诉流程哪一部分用于支撑文章，以及该连接可以执行哪些操作。

工具返回的结果应携带足够信息以支持下一步决策。

Anthropic 的工具设计指南讨论了有用的输出和可操作的错误，包括帮助 Agent 从失败调用中恢复的信息。编写有效的工具

如果检索失败，保留文档标识符和失败原因。在重复同一请求前，先检查身份验证或访问权限。

检查连接器可用的操作，并为会更改外部服务的操作配置权限。

当某些服务器在当前工作流中没有作用时，通过 /mcp 禁用它们。

4. 把操作规则放在执行层

定义工作流可以修改哪些文件，以及哪些操作需要审批。

权限规则作用于工具边界。

PreToolUse hook 可以在执行前检查拟议的操作。

当决策依赖于参数或任务状态时使用它，例如目标路径是否匹配已批准的输出。Hook 参考

将以下内容合并到 .claude/settings.json：

1{
2  "permissions": {
3    "deny": [
4      "Read(.env)",
5      "Read(.env.*)",
6      "Edit(published/**)"
7    ]
8  }
9}

`Read` 规则覆盖指定的环境文件。`Edit` 规则通过内置的编辑和写入工具保护 `published/` 下的文件。权限语法。

打开 `/permissions` 并检查生效的规则。

现有配置和托管策略可能会影响会话允许的操作，因此保存后要检查加载结果。

做一个无害的练习：在 `published/` 中创建一个假文档，然后让 Claude 通过其文件编辑工具去修改它。该操作应该被拒绝。

文件工具的限制有明确的作用范围。

任意的 Python 或 Node 进程可以通过自身代码访问文件；需要时，操作系统级沙箱可在这些进程之间提供限制。

对于外部写入，要明确目标和正在批准的确切内容。如果内容发生变化，在执行前重新审查更新后的操作。

超时同样需要明确的恢复步骤。

重试外部写入前先检查目标，因为第一次尝试可能已经完成。

5. 让审核员返回证据

给验证工作设定一个有边界的任务，并提供主 Agent 可用的报告。

subagent 拥有自己的上下文和可配置的工具来完成这项工作。Subagent 配置

审核员应收到草稿路径、相关来源位置，以及需要检查的主张。

明确规定它应如何报告不确定性。

将以下内容粘贴到 .claude/agents/evidence-reviewer.md：

1---
2name: evidence-reviewer
3description: 使用一手来源验证草稿中的事实主张。
4tools: Read, Grep, Glob, WebSearch, WebFetch
5effort: high
6---
7阅读提供的草稿及其素材。
8对照已打开的一手来源核查事实主张。
9返回一张表格：主张、结论、来源 URL、所需更正。
10使用以下结论：verified（已验证）、incorrect（错误）、unresolved（未解决）。
11对于未解决的主张，说明缺少哪些证据。

这个 worker 会获得读取和搜索工具。

草稿更正仍由主 Agent 负责。

每项发现都应把一条主张与一个已打开的来源关联起来。

像 incorrect 这样的结论需要提供冲突证据，以及作者可以直接应用的更正。

unresolved 结论应指出缺失的证据。

主 Agent 审查这些发现、更新草稿，并检查修改后的措辞。即使审核员的报告很自信，其建议背后仍需有可用的证据支撑。

当某处更正改变了整段含义时，重新检查相邻句子。

Anthropic 的评估指南将 Agent 的记录与环境中的最终结果区分开来。

它还描述了针对不同类型结果的不同检查方法。Agent 评估

在这里应用这一区分：打开已保存的草稿，并检查其中引用的主张。

审核表应描述真正会被接受的那份文档。

6. 为工作分配合适的推理强度

主会话从 `medium` 开始；除非有适用的设置覆盖，否则 Opus 5.5 会使用该默认值。

上面的审核员为其验证工作请求了 `high`。Effort 配置

安装好 Claude Code 并登录账号后，在工作区根目录运行：

1claude --model claude-opus-5-5 --effort medium

在会话头部确认 Opus 5.5 和当前生效的 effort。

启动命令为该会话设置模型和 effort。

可以为 skill 或 subagent 配置 effort，但受限于模型支持的级别和适用的限制。

在指令中写关于思考深度的要求，并不会改变已配置的 effort 设置。

选择一个在更改设置前能检查结果的任务。记录哪些验收检查通过了，以及输出需要哪些更正。

这让 effort 成为与具体工作绑定的决策。

涉及模糊主张的素材审查可以有自己独立的配置，而主起草工作流保持其选定的级别。

首次运行前，使用 `/context` 检查已加载的指令，`/agents` 确认审核员，`/permissions` 检查操作规则。

在分配完整任务前，先修复缺失的组件。

7. 告诉这次运行它必须证明什么

用已保存的交付物和验证结果来定义完成。

一份草稿、它的核查表和一条更新的进度记录，为运行提供了具体的产出目标。

Claude Code 的 `/goal` 会根据对话轮次间呈现的证据来评估完成条件。评估器依赖 Agent 展示相关结果。Goal 文档

把主题、参考资料和来源链接放入 `sources/`。然后将以下内容粘贴到 Claude Code：

1/goal 使用 write-draft 根据 sources/ 准备一篇文章。完成条件要求 drafts/article.md 和 drafts/checks.md 存在，错误主张已被更正，未解决的主张已被明确标记，并且输出路径和验证结果出现在对话中。若 12 轮后条件仍未满足则停止，并报告阻碍因素。

轮次条款由模型评估。严格的运行时或开销限制需要执行控制，而 `/goal clear` 会移除当前活动的 goal。

运行结束后，打开这两个文件并检查几处主张与来源的对应关系。

确认进度记录与工作区中保存的工作一致。

对下一个任务使用相同的证据格式。

一致的报告让你无需重建整个对话，就能识别未解决的主张和缺失的检查。

为了恢复，`/rewind` 可以还原被跟踪的文件编辑。Shell 变更和大多数 subagent 编辑需要单独恢复，而版本控制可保留持久的文件历史。检查点限制

完整运行一次工作流

在启动会话前创建来源文件夹和四个配置文件 => 在素材旁放一份简短的任务说明，让期望结果保持明确。

将以下内容复制到 sources/task.md 并填写细节：

1主题：[具体主题]
2读者：[谁需要这份说明]
3交付物：一篇包含实操步骤和官方来源的文章。
4验收标准：涵盖必需主题；事实主张已核查；
5未解决的主张已标记；草稿和审核表已保存。
6约束：[长度、风格、排除的主题]

用第六层的命令启动 Claude Code 并检查加载的配置 => 运行第七层的 goal，然后检查保存的输出。

预期结果是 `drafts/article.md`、`drafts/checks.md` 和 `progress.md`。

核查表应标明哪些已验证，哪些仍需你关注。

如果 skill 缺失，检查其路径和 frontmatter。

如果审核员缺失，检查其 `name` 和 `description`，然后通过 `/agents` 确认可用性。

对于未解决的主张，检查提供的来源以及审核员要求的证据。

在接受草稿前，要么补上缺口，要么让它保持明显标记。

检查下一次会话能恢复什么

在每个有意义的阶段之后维护 `progress.md`。

记录当前文件、已完成的检查、未决问题和下一步行动。

根目录的 CLAUDE.md 会在压缩（compaction）后被重新读取。

作用域指令会在访问相关文件时重新加载。压缩与记忆

用这种紧凑的结构来写进度记录：

1任务：[当前主题]
2输出：[草稿和审核路径]
3已完成：[已完成的阶段和检查]
4决策：[已确认的选择及其来源]
5未决问题：[缺失的证据或阻碍因素]
6下一步行动：[一个具体的继续步骤]

在同一工作区启动一个新会话并粘贴：

1阅读 progress.md 并检查其中引用的草稿和核查表。
2从记录的下一步行动继续，并更新进度记录。

会话应能识别已保存的工作并从交接点继续。如果它从头开始，检查记录并补充缺失的决策或文件路径。

Anthropic 的长时运行 Agent 指南使用持久化进度记录来支持跨会话工作。

随着任务变化维护这些记录，这样恢复的运行才能掌握最新信息。长时运行的 harness

用已接受的工作衡量这套配置

使用 `/usage` 检查报告的用量，使用 `/context` 查看工作上下文中占用了什么。把委派的审核和重试计入任务总量。用量指南

记录你的审核时间以及结果所需的更正。

需要大量修补的输出会改变整次运行的价值。

测试配置变更时，保持任务和验收标准一致。

调整一个组件，重复任务，然后检查保存的结果及其证据。

Anthropic 早期测试者报告中提到的 60% token 减少属于那次模型实验。

通过衡量已完成的任务，来确定你自己的 harness 节省了多少。Opus 5.5 公告

首次运行被接受后，用新的主题和素材集复用该 skill。保持审核员、输出路径和完成格式一致，当反复出现的更正揭示出缺失步骤时再更新流程。

保存这篇文章以免丢失

关注 @beamnxw 获取更多 alpha :)

=> 我的 substack

=> 我的 telegram 频道