feat: 在 system prompt 中注入平台执行约束

[lishuceo]

Summary

• 将 Feishu bot 平台限制硬编码到 buildWorkspaceSystemPrompt 中
• 覆盖三个约束：子进程生命周期、长任务正确模式、权限交互
• 所有通过 anycode 执行的 agent 自动获得这些知识

背景

urhox-bench 场景中 Agent 使用 Monitor 等待 20-25 分钟的 Sonnet 跑批结果，但 query 返回后子进程被回收，Monitor 随之终止。这不是 bug 而是架构差异（CLI 长驻进程 vs SDK query-per-interaction 模型），需要让 Agent 知道正确的长任务模式。

之前放在 config/knowledge/platform.md（gitignored），新部署/其他开发者无法受益。现在移到代码中，所有人自动获得。

Test plan

• 新 query 的 system prompt 中包含"平台执行约束"段落
• 不影响目标仓库的 CLAUDE.md（原生 CLI/Codex 用户不受约束）
• Agent 在长任务场景使用 nohup + cron 模式而非 Monitor

🤖 Generated with Claude Code

[github-actions]

Claude finished @lishuceo's task in 2m 45s —— View job

---

Code Review: 平台执行约束注入

Verdict: ⚠️ 一处值得修正 + 测试缺口

变更本身干净、低风险——纯粹是把一段静态约束文本追加到 buildWorkspaceSystemPrompt 的 basePrompt 末尾。我核对了文本中引用的工具/参数是否与实现一致，发现一个真实问题。

---

🟡 manage_cron 默认不可用，但 prompt 无条件引用它 (置信度 ~80)

src/claude/executor.ts:486 指示 agent：

用 cron 工具（manage_cron）设一个一次性定时检查（schedule_kind: "at"）

但 cron MCP server 是条件注册的（executor.ts:709）：

if (config.cron.enabled) {
  ...
  mcpServers['cron-scheduler'] = createCronMcpServer({ ... });
}

而 config.cron.enabled = process.env.CRON_ENABLED === 'true'（src/config.ts:193）——默认关闭。

后果：在未显式设置 CRON_ENABLED=true 的默认部署中，平台约束 prompt 被无条件追加，agent 在长任务场景会按指示调用 manage_cron，但该工具根本没注册，调用会失败，"正确的长任务模式"反而走不通。

建议二选一：

• 让这段 cron 相关指引随 config.cron.enabled 条件拼接（cron 关闭时降级为"启动后台任务并告知用户稍后手动追问"）；或
• 在文档/部署说明中明确：要让长任务模式生效需开启 CRON_ENABLED=true。

工具名 manage_cron 和 schedule_kind: "at" 本身与实现一致（src/cron/tool.ts:28,42），没问题。

🟡 缺少测试 (CLAUDE.md 测试策略)

CLAUDE.md 明确："新功能必须附带单元测试……每个 feat commit 必须伴随对应的 test commit"。本 PR 是 feat，但没有测试，PR 描述里的 Test plan 三项也都未勾选。

buildWorkspaceSystemPrompt 当前是模块私有函数（executor.ts:325，未 export），加一个断言"system prompt 含'平台执行约束'段落"的测试需要先 export 它。改动很小，建议补上，以满足仓库测试策略并锁定这段约束不被误删。

Fix this →

---

✅ 其余确认无误

• nohup ... & 脱离子进程的建议是对的——子进程被回收后被 nohup 的进程会被 reparent 到 init 存活，cron 检查由服务级 scheduler（非子进程）触发，模式自洽。
• 不影响目标仓库 CLAUDE.md，约束只进 anycode 的 appendSystemPrompt，原生 CLI/Codex 用户不受影响——符合 PR 意图。
• 把约束从 gitignored 的 config/knowledge/platform.md 移入代码，避免误删、惠及所有部署——方向正确。

整体是一个合理的小改动，建议处理上面的默认 cron 问题后再合并。
· feat/platform-constraints-prompt

[lishuceo]

Fixed — 处理了 review 指出的两个问题：

1. manage_cron 条件化 — cron 指引现在根据 config.cron.enabled 动态拼接。cron 关闭时降级为"建议用户稍后手动追问检查结果"，不再无条件引用不存在的工具。

2. 补充测试 — export buildWorkspaceSystemPrompt 并添加了测试用例，断言 system prompt 包含平台约束段落、cron 关闭时不出现 manage_cron。

[github-actions]

Claude finished @lishuceo's task in 1m 42s —— View job

---

Re-review: 平台执行约束注入 (fixes)

Verdict: ✅ Approved — 2 previous issues fixed

上一轮 review 指出的两个问题均已正确处理。

• 读取最新代码与测试
• 确认 manage_cron 指引已条件化
• 确认测试已补充
• 核对测试在 mock 环境下可通过
• 给出最终结论

---

✅ 1. manage_cron 已条件化 (已修复)

src/claude/executor.ts:486-487 现在按 config.cron.enabled 三元拼接：

• cron 开启 → 指引使用 manage_cron + schedule_kind: "at"
• cron 关闭（默认）→ 降级为"立即返回，建议用户稍后手动追问检查结果"，不再无条件引用未注册的工具

逻辑与 executor.ts:709 的条件注册一致，默认部署不再产生"指引调用一个不存在的工具"的矛盾。

✅ 2. 测试已补充 (已修复)

buildWorkspaceSystemPrompt 已 export，src/claude/__tests__/executor.test.ts:585-600 新增两个用例：

• 断言 system prompt 含「平台执行约束 / 子进程生命周期 / Monitor 警告 / 权限交互」段落
• 断言 cron 关闭时不出现 manage_cron，且出现降级文案

mock 的 config.cron.enabled = false（test:19），与第二个断言匹配。另核对：buildWorkspaceSystemPrompt('/tmp/work') 非 restart 路径会触发 listAvailableProjects / listKnownOrgs，二者内部 readdirSync 虽未被 mock，但都包在 try/catch 中返回 []（executor.ts:248-258、301+），因此测试在当前 mock 下仍能稳定通过。

---

备注（非阻塞）

• 测试只覆盖了 cron 关闭分支；cron 开启时 prompt 含 manage_cron 的正向断言可作为可选补充，用于锁定两个分支。当前覆盖已满足 CLAUDE.md 测试策略，不强制。
• 平台约束位于 basePrompt，在 isRestart 下同样注入——符合预期（重启后约束仍应生效）。

整体是干净、低风险的改动，两个 review 点都已闭环。建议合并。