# Grok Bot + Claude: How to Build an AI Team That Works While You Sleep
**作者**: kvro
**日期**: 2026-10-23T17:05:34.000Z
**来源**: [https://x.com/0xkvro/status/2113678227096961252](https://x.com/0xkvro/status/2113678227096961252)
---
One AI manager. Four specialized workers. Shared memory. Automated workflows. A complete operating system for getting real work done without managing every step yourself.
Most people are going to use Grok Bot and Claude completely wrong.
They'll connect the most powerful model available, give it an enormous prompt, ask it to build something, and watch the screen for the next twenty minutes.
Then they'll call it an autonomous AI employee.
That's not an AI employee.
That's a chatbot doing a longer task.
The real opportunity is much bigger.
Imagine opening your laptop in the morning and finding that your AI team has already investigated three GitHub issues, reproduced two bugs, prepared a fix, run the tests, reviewed the changes, and left everything organized for your approval.
No digging through conversations.
No asking what happened overnight.
No reconstructing half-finished tasks.
Just completed work, supporting evidence, and the decisions that actually need you.
This is the system I would build with Grok Bot and Claude.
Not one giant agent with unlimited permissions.
A coordinated team with specialized responsibilities, persistent task state, a memory system that knows what to keep and what to forget, and automated routines that turn instructions into review-ready results.
Here's the complete architecture.
## 1. Stop Building Chatbots. Build an Operating System.
A good AI model can solve difficult problems.
But solving one problem inside a conversation isn't the same as owning a workflow.
A real employee knows what they're responsible for, where the necessary files live, which tasks are unfinished, what decisions have already been made, and when they need approval.
An AI system needs the same structure.
That's where the combination of Grok Bot and Claude gets interesting.
Grok Bot can provide the coordination environment: supported tools, computer operations, task handoffs, connected applications, and recurring routines.
Claude can contribute research, coding, reasoning, and review through a separately configured Claude Code or API workflow.
If Grok Bot supports multiple backend models, its own routing determines which model handles a given request. That isn't the same as guaranteeing Claude for every task.
So I wouldn't build the architecture around an assumption about which model answers next.
I'd build it around something more durable.
The model can change. The workflow should survive.
The system needs six components:
A coordinator that owns the outcome.
Specialists with clearly defined jobs.
A workspace that preserves artifacts.
A memory layer that distinguishes current decisions from outdated observations.
A verification process that checks actual work.
And an approval boundary that prevents autonomous agents from taking actions they shouldn't.
That's the foundation.
## 2. One Chief. Four Specialists. No Confusion.
The first mistake people make with multi-agent systems is creating several agents that all do roughly the same thing.
Five agents independently analyzing the same request don't automatically create a team.
They create five opportunities to disagree.
Instead, I would assign five distinct roles.
Chief - Grok Bot
Chief receives new assignments, determines which specialist should handle them, tracks progress, resolves handoffs, and prepares the final status report.
Chief doesn't need to write every line of code.
It needs to know whether the work is actually finished.
Researcher
Researcher investigates the problem, collects relevant evidence, reads documentation, and identifies missing information.
Its job is to reduce uncertainty before implementation begins.
Builder - Claude
Builder turns the approved plan into working code, scripts, documents, or other deliverables.
For software tasks, a dedicated Claude Code environment is particularly useful because it can operate on a real project and run development commands when properly configured.
Reviewer
Reviewer independently examines what Builder produced.
It should inspect actual changes, test outputs, and acceptance criteria instead of merely trusting a success summary.
Reporter
Reporter assembles the final deliverable, links to supporting artifacts, identifies unfinished work, and asks for approvals when necessary.
The result is a division of labor that looks much closer to an engineering team than a collection of chat windows.
The most important detail is that the workers return artifacts.
Not confidence.
Not vague progress updates.
Evidence.
## 3. Give the Team a Real Workspace
A conversation is a terrible place to run a long-term operation.
Important details get buried.
Tool outputs disappear into old messages.
One agent finishes something while another still believes it's unfinished.
The solution is to keep task state outside the conversation.
I would start with a small shared project structure:
```
/workspace/ai-team/
│
├── inbox/
├── active/
├── research/
├── builds/
├── reviews/
├── completed/
├── memory/
└── logs/
```
Every task receives a unique ID and one current owner.
Every significant action produces a file, link, log, or recorded decision.
Every handoff updates the task status.
This doesn't require an expensive infrastructure stack.
A few structured files and a Git repository can be enough for the first version.
For a new GitHub issue, the workspace might contain:
```
active/issue-104/
│
├── task.md
├── status.json
├── research.md
├── implementation.md
├── test-results.txt
├── review.md
└── handoff.md
```
Now a new agent session can inspect the project and continue from the recorded state.
It doesn't have to pretend to remember an entire conversation.
There's also an important operational detail: agents sharing one cloud computer may share files and credentials. Different agent names do not automatically create isolated security environments.
For parallel coding work, use separate branches or isolated development environments where available.
The goal is coordinated work without conflicting edits or unnecessary access.
## 4. The Prompt That Turns Grok Bot Into Chief
The first useful prompt should define responsibilities, not personality.
I would start with this:
You are Chief, the coordinator of my AI team.
Your workspace is:
/workspace/ai-team
Your job is to turn approved assignments
into verified, review-ready deliverables.
For each task:
1. Assign a unique task ID.
2. Define the expected result.
3. Identify required evidence.
4. Select the responsible specialist.
5. Record progress in the task ledger.
6. Check for blockers and failed attempts.
7. Require independent review.
8. Prepare a final handoff.
Never mark work complete solely because
another agent claims success.
Never deploy, publish, delete important data,
or make irreversible changes without approval.
If evidence is missing, report BLOCKED.
Always tell me:
- What was completed
- What was verified
- What failed
- What needs my decision
This gives the coordinator a measurable job.
It also prevents one of the most common agent failures: confusing a convincing explanation with a completed action.
The system should not report that a bug was fixed because Builder said it was.
It should report that a bug was fixed because the relevant code changed, the regression test passed, and the review found no blocking issue.
A completed task needs a receipt.
## 5. Claude Should Build. Another Agent Should Challenge.
Now give Builder a real assignment.
Suppose a GitHub issue reports that users cannot save a particular form.
The weak workflow is obvious.
Claude reads the description, modifies a function, and announces that the problem is solved.
But maybe the change fixes one symptom and introduces another bug.
Maybe the test suite never ran.
Maybe the original problem couldn't even be reproduced.
A stronger workflow separates investigation, implementation, and review.
First, Researcher identifies the expected behavior and collects reproduction evidence.
Then Builder receives the evidence and creates the smallest appropriate fix.
Here's the Builder instruction:
You are Builder.
Your responsibility is to implement
approved tasks using Claude Code
or another configured coding environment.
Before writing code:
- Read the task requirements
- Inspect the relevant project files
- Review reproduction evidence
- Identify the acceptance criteria
During implementation:
- Work on a separate branch
- Make the smallest reasonable change
- Preserve existing behavior
- Add or update tests where appropriate
Before returning:
- Run relevant tests
- Save the actual test output
- List changed files
- Explain remaining risks
- Prepare a draft pull request if supported
Never merge or deploy automatically.
If you cannot run a required check,
report that limitation explicitly.
After Builder finishes, Reviewer gets a different job.
Not to praise the implementation.
To find weaknesses.
You are Reviewer.
Independently verify Builder's work.
Inspect:
- Original task
- Acceptance criteria
- Code changes
- Test output
- Relevant edge cases
- Possible regressions
Return exactly one status:
PASS
FAIL
BLOCKED
For FAIL:
Explain the problem, identify the
relevant file or behavior, and describe
the evidence supporting your finding.
For BLOCKED:
Explain which evidence or access is missing.
Do not approve work solely from
Builder's summary.
Do not modify the implementation yourself.
This is the difference between generating work and verifying work.
A language model can be remarkably good at both tasks.
But giving those tasks to independent stages makes failures easier to detect.
## 6. The Memory Problem Nobody Notices Until Week Two
Here's where most long-running AI teams begin to fall apart.
Imagine Chief is managing a software release.
On Monday, an integration test fails.
The system stores the result.
On Tuesday, the developer fixes the problem.
On Wednesday, the test passes.
But on Thursday, a new session retrieves Monday's summary.
The agent confidently tells the user the release is still blocked.
Nothing went wrong with storage.
The system remembered the old information perfectly.
It failed to recognize that the information had expired.
That's why a good AI memory stack needs more than conversation summaries.
It needs to distinguish between durable rules, temporary observations, task checkpoints, and current evidence.
For example:
"The production deployment requires approval" is a durable rule.
"Integration test failed Monday" is a dated observation.
"Builder has completed the patch" is task state.
"The latest CI run passed" is current evidence from an external system.
Those facts have different lifetimes and different authority.
Treating them as one giant memory file makes an AI team less reliable as its history grows.
An agent that remembers everything can still make decisions using yesterday's truth.
## 7. Build Memory That Knows What to Forget
I would make the memory system deliberately selective.
Every durable record should contain a type, source, scope, timestamp, and review condition.
A simple example:
```
{
"id": "release-approval-rule",
"type": "decision",
"scope": "engineering",
"rule": "Production deployments require human approval",
"source": "approved-workflow.md",
"status": "active",
"review_on": "policy_change"
}
```
A temporary observation should look different:
```
{
"id": "issue-104-ci-status",
"type": "observation",
"task": "issue-104",
"value": "tests_failed",
"source": "ci-run-418",
"status": "needs_recheck"
}
The key
```
The key idea is that memory doesn't become the ultimate authority.
It points the system toward the source of truth.
If a new CI run replaces the old result, the agent must use the new evidence.
If a task is complete, its temporary checkpoint should stop appearing in unrelated sessions.
If a user changes an approved decision, the system should record the revision rather than silently mixing two contradictory instructions.
This is the memory design I would actually trust for long-running work.
Store fewer things.
Preserve their sources.
Check freshness when necessary.
And make old assumptions easy to retire.
## 8. Stop Treating a Chat Summary Like a Database
A large context window is useful.
It is not a replacement for state management.
Imagine restarting a development agent after several hours of work.
The agent receives a compressed summary saying:
"Work on issue 104 is nearly complete."
What does nearly complete mean?
Were the tests run?
Did Reviewer approve the change?
Was the pull request created?
Is there a blocking failure?
A useful checkpoint should answer those questions precisely.
TASK: issue-104
GOAL:
Fix form-save failure
DONE:
Bug reproduced
Fix implemented
Regression test added
VERIFIED:
Unit tests passed
OPEN:
Independent review pending
APPROVAL:
Merge not authorized
NEXT:
Send diff and test output to Reviewer
This record can survive a session interruption.
It also tells a fresh agent exactly where to continue.
Compaction can help preserve continuity during a long run, but a compressed narrative is not a substitute for actual test results and task artifacts.
The agent should always be able to reopen the evidence.
This one design choice prevents a surprising amount of wasted work.
## 9. Make the Workflow a State Machine
Once the memory and workspace exist, define the only valid states a task can enter.
Every transition requires evidence.
BUILDING cannot become TESTING without an implementation artifact.
TESTING cannot become REVIEWING without recorded test results or a clearly documented blocker.
REVIEWING cannot become REVIEW_PASSED without an independent review decision.
READY_FOR_APPROVAL does not mean the AI has permission to deploy.
The permissions should also be enforced by external mechanisms such as branch protection, tool access restrictions, and approval controls.
A prompt alone is not a security boundary.
This structure gives the AI team something much more valuable than an elaborate persona.
A reliable definition of progress.
## 10. The Night Shift: Work That Continues After You Close the Laptop
Now the interesting part.
Once one full workflow has passed manual testing, Grok Bot can coordinate scheduled routines using its supported integrations and available execution environment.
I would start with a deliberately narrow nightly assignment.
Not "maintain my entire company."
Not "improve every repository."
Just investigate a small number of explicitly approved GitHub issues.
Here's the routine I would configure:
Create a routine called Engineering Night Shift.
Schedule:
Every night at 11:00 PM.
Coordinator:
Chief
Input:
GitHub issues labeled "agent-ready"
in the approved repository.
Limit:
Maximum 2 new issues per run.
Process:
1. Check the active task ledger.
2. Skip duplicate or blocked assignments.
3. Research the selected issues.
4. Reproduce the reported failures.
5. Delegate approved implementation work.
6. Run relevant automated checks.
7. Request independent review.
8. Prepare draft pull requests.
9. Save task checkpoints.
10. Generate a morning report.
Stop if:
- Required access is missing
- The issue cannot be reproduced
- The same repair fails twice
- Sensitive changes need approval
- Execution limits are reached
Never merge or deploy automatically.
A scheduled run isn't an unlimited, unstoppable worker.
Tasks can fail, usage limits can be reached, tools can time out, and external state can change while the agent is inactive.
That's exactly why task checkpoints and recovery rules matter.
The goal is not an AI that never encounters problems.
It's an AI operation that knows how to report problems without inventing success.
## 11. What the Morning Report Should Actually Look Like
Most autonomous-agent demos focus on the moment an agent starts doing something.
I care much more about what remains after it finishes.
The morning report is the real product.
It should contain the actual status of each task and links to supporting artifacts.
For example, a hypothetical engineering night shift could produce this:
ENGINEERING NIGHT SHIFT
ISSUE #104
Status: REVIEW PASSED
Result: Draft PR prepared
Tests: 18 passed, 0 failed
Approval: Merge required
ISSUE #107
Status: BLOCKED
Result: Bug reproduced
Problem: Missing test credentials
Next: Request approved access
SUMMARY
1 draft PR ready
1 issue blocked
0 production deployments
0 unauthorized changes
These are illustrative results, not output from an actual completed agent run.
But the reporting structure is the important part.
Chief should not hide unsuccessful tasks.
Reporter should not describe attempted work as completed work.
And the system should never claim it verified something without being able to identify the actual verification evidence.
## 12. The Rule That Makes the Whole System Safer
There is one principle I would enforce across every specialist.
The AI may prepare consequential actions.
It does not automatically receive permission to perform them.
Reading documentation, running tests, preparing reports, and opening draft pull requests can be allowed within defined environments.
Merging code, deploying to production, deleting records, changing billing systems, and modifying sensitive permissions should require explicit authorization.
That distinction matters because more capable AI models can complete longer action chains.
An agent that can reason through twenty steps also has more opportunities to reach a dangerous twenty-first step.
A well-designed system does not need to stop all automation.
It needs to decide where autonomy ends.
And that boundary should be enforced by the actual systems being accessed, not just described in a prompt.
## 13. The AI Team Should Improve Its Process, Not Rewrite Its Rules
After a completed assignment, Chief can review what made the work slow or unreliable.
Maybe Researcher repeatedly missed an important documentation file.
Maybe Builder struggled because dependencies were not installed.
Maybe Reviewer found the same type of regression in several changes.
Those failures can become reusable workflow improvements.
For example, a validated setup procedure can become a project skill.
A recurring code-review check can become a test.
A common task format can become a template.
But the agent should not silently convert its own guesses into permanent rules.
A proposed improvement is not an approved decision.
A failed run is not automatically evidence that the process should be rewritten.
And a useful lesson from one project should not automatically gain authority over another.
The memory system should preserve reviewed procedures while keeping provisional observations separate.
That's how the team becomes more consistent without becoming more confident in its mistakes.
## 14. The First 24 Hours
I wouldn't start by creating ten agents, connecting every account, and enabling unattended execution.
I'd start with one complete workflow.
Give Chief one low-risk GitHub issue.
Make Researcher investigate it.
Have Builder prepare a fix in an isolated branch.
Require actual tests.
Have Reviewer inspect the changes.
Then let Reporter produce a final handoff.
If the system completes that process correctly, save the successful procedure as a reusable workflow.
Run it again on a second issue.
Check whether the result remains understandable after a fresh session.
Only then consider a scheduled night shift.
Because the goal is not to build the largest AI team possible.
It's to build the smallest team that can reliably finish a meaningful job.
## The Real Shift
Claude can reason about difficult problems, write code, and help produce sophisticated technical work.
Grok Bot can coordinate a persistent working environment and automate supported tasks.
Together, they create an interesting foundation.
But neither model intelligence nor a persistent computer automatically produces a reliable employee.
The missing pieces are ownership, evidence, memory, permissions, and a way to recover when something fails.
That's why this architecture matters.
Chief manages the outcome.
Specialists own their stages.
Claude produces implementation work.
Reviewer challenges the result.
Memory preserves relevant decisions without treating outdated observations as current truth.
Checkpoints make interrupted work recoverable.
Approval controls keep consequential actions under human authority.
And the morning report tells you exactly what happened.
The future of AI agents isn't a chatbot that can work for twenty minutes without interruption.
It's a system you can stop supervising for hours and still understand, verify, and control when you return.
## More From Me
I write about Grok Bot, Claude, AI employees, autonomous engineering, agent memory, multi-agent orchestration, and practical systems that turn AI reasoning into completed work.
Follow @0xkvro for more.
Previous Articles
1. x.com/0xkvro/status/2110395362745651233
2. x.com/0xkvro/status/2108602220014870899
3. x.com/0xkvro/status/2106763188100362388
Bookmark this before building another AI agent that has every tool in the world and no idea what finishing the job actually means.
## 相关链接
- [kvro](https://x.com/0xkvro)
- [@0xkvro](https://x.com/0xkvro)
- [14K](https://x.com/0xkvro/status/2113678227096961252/analytics)
- [@0xkvro](https://x.com/@0xkvro)
- [x.com/0xkvro/status/2110395362745651233](https://x.com/0xkvro/status/2110395362745651233)
- [x.com/0xkvro/status/2108602220014870899](https://x.com/0xkvro/status/2108602220014870899)
- [x.com/0xkvro/status/2106763188100362388](https://x.com/0xkvro/status/2106763188100362388)
- [Upgrade to Plus](https://x.com/i/premium_sign_up)
- [1:05 AM · Oct 24, 2026](https://x.com/0xkvro/status/2113678227096961252)
- [14.3K Views](https://x.com/0xkvro/status/2113678227096961252/analytics)
- [View quotes](https://x.com/0xkvro/status/2113678227096961252/quotes)
---
*导出时间: 2026/10/26 09:59:10*
---
## 中文翻译
# Grok Bot + Claude：如何打造一个在你睡觉时也在工作的 AI 团队
**作者**： kvro
**日期**： 2026-10-23T17:05:34.000Z
**来源**： [https://x.com/0xkvro/status/2113678227096961252](https://x.com/0xkvro/status/2113678227096961252)
**阅读**： 14306
**点赞**： 32
**转发**： 6
**回复**： 2
---
一个 AI 管理者。四名专职工作者。共享记忆。自动化工作流。一套完整的操作系统，让你无需亲自管理每一步就能完成真正的工作。
大多数人使用 Grok Bot 和 Claude 的方式完全是错的。
他们会连接最强大的模型，给它一个巨大的提示词，让它构建某个东西，然后盯着屏幕看接下来的二十分钟。
然后他们称之为“自主 AI 员工”。
那不是 AI 员工。
那只是一个执行较长任务的聊天机器人。
真正的机会要大得多。
想象一下，早上打开笔记本电脑，发现你的 AI 团队已经调查了三个 GitHub issue，复现了两个 bug，准备好了修复方案，运行了测试，审查了改动，并把一切都整理好等待你的批准。
无需翻阅对话记录。
无需询问夜里发生了什么。
无需重建半途而废的任务。
只有完成的工作、支撑证据，以及真正需要你决策的事项。
这就是我会用 Grok Bot 和 Claude 构建的系统。
不是一个拥有无限权限的巨型智能体。
而是一个分工明确、责任清晰的团队：有持久化的任务状态，有知道该保留什么、该遗忘什么的记忆系统，还有能把指令转化为可审查成果的自动化例程。
下面是完整的架构。
## 1. 别再构建聊天机器人了。构建一个操作系统。
好的 AI 模型可以解决难题。
但在对话中解决一个问题，并不等于拥有一个完整的工作流。
一个真正的员工知道自己负责什么、必要的文件存放在哪里、哪些任务未完成、已经做了哪些决策，以及何时需要批准。
AI 系统也需要同样的结构。
这就是 Grok Bot 和 Claude 组合变得有趣的地方。
Grok Bot 可以提供协调环境：支持的工具、计算机操作、任务交接、连接的应用，以及可重复执行的例程。
Claude 可以通过单独配置的 Claude Code 或 API 工作流贡献研究、编码、推理和审查能力。
如果 Grok Bot 支持多个后端模型，它自己的路由决定由哪个模型处理给定的请求。这并不等于保证每个任务都由 Claude 处理。
所以我不会围绕“下一个响应的是哪个模型”这一假设来构建架构。
我会围绕更持久的东西来构建。
模型可以更换。工作流应该延续。
系统需要六个组件：
一个对结果负责的协调者。
职责明确的专家。
一个保存产出物的工作区。
一个能把当前决策与过时观察区分开的记忆层。
一个检查实际工作的验证流程。
以及一个防止自主智能体做出不应有动作的审批边界。
这就是基础。
## 2. 一个主管。四名专家。绝不含糊。
人们使用多智能体系统时犯的第一个错误，是创建几个大致做同样事情的智能体。
五个智能体各自独立分析同一个请求，并不会自动组成一个团队。
它们只会制造出五个产生分歧的机会。
相反，我会分配五个不同的角色。
Chief（主管）— Grok Bot
Chief 接收新任务，决定由哪位专家处理，跟踪进度，处理交接，并准备最终状态报告。
Chief 不需要编写每一行代码。
它需要知道工作是否真正完成。
Researcher（研究员）
Researcher 调查问题，收集相关证据，阅读文档，并识别缺失的信息。
它的职责是在实施开始之前减少不确定性。
Builder（构建者）— Claude
Builder 把已批准的计划转化为可运行的代码、脚本、文档或其他交付物。
对于软件任务，专门的 Claude Code 环境尤其有用，因为在配置得当的情况下，它可以在真实项目上操作并运行开发命令。
Reviewer（审查者）
Reviewer 独立检查 Builder 的产出。
它应该检查实际的改动、测试输出和验收标准，而不是仅仅相信一份“成功”总结。
Reporter（汇报者）
Reporter 汇总最终交付物，链接支撑性产出物，标明未完成的工作，并在必要时请求批准。
其结果是一个更接近工程团队的分工，而不是一堆聊天窗口。
最重要的细节是：工作者要交回产出物。
不是自信。
不是模糊的进度更新。
是证据。
## 3. 给团队一个真正的工作区
对话是运行长期操作的糟糕场所。
重要细节被淹没。
工具输出消失在旧消息里。
一个智能体完成了某项工作，而另一个智能体仍以为它未完成。
解决方案是把任务状态保存在对话之外。
我会从一个小的共享项目结构开始：
```
/workspace/ai-team/
│
├── inbox/
├── active/
├── research/
├── builds/
├── reviews/
├── completed/
├── memory/
└── logs/
```
每个任务都有一个唯一 ID 和唯一当前负责人。
每个重要动作都会产生一个文件、链接、日志或记录在案的决策。
每次交接都会更新任务状态。
这不需要昂贵的基础设施。
几个结构化文件和一个 Git 仓库，对第一版来说就足够了。
对于一个新 GitHub issue，工作区可能包含：
```
active/issue-104/
│
├── task.md
├── status.json
├── research.md
├── implementation.md
├── test-results.txt
├── review.md
└── handoff.md
```
现在，一个新的智能体会话可以检查项目，并从记录的状态继续。
它不必假装记得整场对话。
还有一个重要的操作细节：共享一台云电脑的智能体可能共享文件和凭证。不同的智能体名称不会自动创建隔离的安全环境。
对于并行的编码工作，应尽可能使用单独的分支或隔离的开发环境。
目标是协调工作，避免冲突的编辑和不必要的访问。
## 4. 把 Grok Bot 变成 Chief 的提示词
第一个有用的提示词应该定义职责，而不是性格。
我会这样开始：
You are Chief, the coordinator of my AI team.
Your workspace is:
/workspace/ai-team
Your job is to turn approved assignments
into verified, review-ready deliverables.
For each task:
1. Assign a unique task ID.
2. Define the expected result.
3. Identify required evidence.
4. Select the responsible specialist.
5. Record progress in the task ledger.
6. Check for blockers and failed attempts.
7. Require independent review.
8. Prepare a final handoff.
Never mark work complete solely because
another agent claims success.
Never deploy, publish, delete important data,
or make irreversible changes without approval.
If evidence is missing, report BLOCKED.
Always tell me:
- What was completed
- What was verified
- What failed
- What needs my decision
这给了协调者一份可衡量的工作。
它还防止了最常见的智能体失败之一：把令人信服的解释误认为是已完成的动作。
系统不应该因为 Builder 说 bug 修好了就报告 bug 已修复。
它应该报告 bug 已修复，是因为相关代码发生了变更、回归测试通过了，并且审查没有发现阻塞性问题。
完成的任务需要一张“回执”。
## 5. Claude 负责构建。另一个智能体负责挑战。
现在给 Builder 一份真正的任务。
假设一个 GitHub issue 报告用户无法保存某个表单。
薄弱的工作流显而易见。
Claude 读取描述，修改一个函数，然后宣布问题已解决。
但也许这个改动修复了一个症状，却引入了另一个 bug。
也许测试套件从未运行过。
也许原始问题根本无法复现。
更强的做法是把调查、实施和审查分开。
首先，Researcher 确定预期行为并收集复现证据。
然后 Builder 接收这些证据，并做出最小的适当修复。
以下是 Builder 的指令：
You are Builder.
Your responsibility is to implement
approved tasks using Claude Code
or another configured coding environment.
Before writing code:
- Read the task requirements
- Inspect the relevant project files
- Review reproduction evidence
- Identify the acceptance criteria
During implementation:
- Work on a separate branch
- Make the smallest reasonable change
- Preserve existing behavior
- Add or update tests where appropriate
Before returning:
- Run relevant tests
- Save the actual test output
- List changed files
- Explain remaining risks
- Prepare a draft pull request if supported
Never merge or deploy automatically.
If you cannot run a required check,
report that limitation explicitly.
Builder 完成后，Reviewer 会得到一份不同的工作。
不是赞美这个实现。
而是找出弱点。
You are Reviewer.
Independently verify Builder's work.
Inspect:
- Original task
- Acceptance criteria
- Code changes
- Test output
- Relevant edge cases
- Possible regressions
Return exactly one status:
PASS
FAIL
BLOCKED
For FAIL:
Explain the problem, identify the
relevant file or behavior, and describe
the evidence supporting your finding.
For BLOCKED:
Explain which evidence or access is missing.
Do not approve work solely from
Builder's summary.
Do not modify the implementation yourself.
这就是生成工作与验证工作之间的区别。
一个语言模型可以在这两项任务上都表现得非常出色。
但把这两项任务交给独立的阶段，可以让失败更容易被发现。
## 6. 没人注意到、直到第二周才爆发的记忆问题
大多数长期运行的 AI 团队正是在这里开始崩溃的。
想象 Chief 正在管理一次软件发布。
周一，一个集成测试失败了。
系统保存了该结果。
周二，开发者修复了问题。
周三，测试通过了。
但到了周四，一个新的会话检索到了周一的总结。
智能体信心满满地告诉用户发布仍被阻塞。
存储没有任何问题。
系统完美地记住了旧信息。
它没能识别出这条信息已经过期。
这就是为什么一个好的 AI 记忆栈需要的不仅仅是会话总结。
它需要区分持久规则、临时观察、任务检查点和当前证据。
例如：
“生产环境部署需要批准”是持久规则。
“集成测试周一失败”是带日期的观察。
“Builder 已完成补丁”是任务状态。
“最新的 CI 运行通过了”是来自外部系统的当前证据。
这些事实有不同的生命周期和不同的权威性。
把它们当作一个巨大的记忆文件，会让 AI 团队随着历史增长而变得越发不可靠。
一个记住了一切的智能体，仍可能根据昨天的真相做出决策。
## 7. 构建知道该遗忘什么的记忆
我会让记忆系统带有明确的筛选性。
每条持久记录都应包含类型、来源、范围、时间戳和复审条件。
一个简单的例子：
```
{
"id": "release-approval-rule",
"type": "decision",
"scope": "engineering",
"rule": "Production deployments require human approval",
"source": "approved-workflow.md",
"status": "active",
"review_on": "policy_change"
}
```
一条临时观察应该看起来不同：
```
{
"id": "issue-104-ci-status",
"type": "observation",
"task": "issue-104",
"value": "tests_failed",
"source": "ci-run-418",
"status": "needs_recheck"
}
The key
```
关键思想是：记忆不应成为终极权威。
它只是把系统指向真相的来源。
如果一次新的 CI 运行取代了旧结果，智能体必须使用新证据。
如果任务已完成，它的临时检查点就不应再出现在无关的会话中。
如果用户更改了已批准的决策，系统应记录这一修订，而不是默默地把两条矛盾的指令混在一起。
这才是我真正信任、可用于长期工作的记忆设计。
存储更少的东西。
保留其来源。
必要时检查新鲜度。
并让旧的假设易于退役。
## 8. 别把聊天总结当作数据库
大的上下文窗口很有用。
但它不能替代状态管理。
想象一下，在几个小时的工作后重启一个开发智能体。
智能体收到一份压缩总结，写着：
"Issue 104 的工作已接近完成。"
“接近完成”是什么意思？
测试运行了吗？
Reviewer 批准这个改动了吗？
Pull request 创建了吗？
是否有阻塞性失败？
一个有用的检查点应该精确回答这些问题。
TASK: issue-104
GOAL:
Fix form-save failure
DONE:
Bug reproduced
Fix implemented
Regression test added
VERIFIED:
Unit tests passed
OPEN:
Independent review pending
APPROVAL:
Merge not authorized
NEXT:
Send diff and test output to Reviewer
这样的记录可以经受住会话中断。
它还能告诉一个全新的智能体究竟该从哪里继续。
压缩可以在长时间运行中帮助保持连续性，但一段压缩后的叙述不能替代实际的测试结果和任务产出物。
智能体应该始终能够重新打开证据。
这一个设计选择就能避免数量惊人的浪费工作。
## 9. 把工作流变成状态机
一旦记忆和工作区就位，就要定义任务可以进入的唯一合法状态。
每一次状态转换都需要证据。
BUILDING 不能在没有实现产出物的情况下变成 TESTING。
TESTING 不能在没有记录在案的测试结果或明确记录的阻塞项的情况下变成 REVIEWING。
REVIEWING 不能在没有独立审查决定的情况下变成 REVIEW_PASSED。
READY_FOR_APPROVAL 不意味着 AI 有部署权限。
权限还应由外部机制强制执行，例如分支保护、工具访问限制和审批控制。
仅靠提示词并不是安全边界。
这种结构给了 AI 团队一样比精致人设宝贵得多的东西。
一个可靠的“进展”定义。
## 10. 夜班：在你合上笔记本后继续的工作
现在是有趣的部分。
一旦一个完整工作流通过了人工测试，Grok Bot 就可以利用其支持的集成和可用的执行环境来协调定时例程。
我会从一个刻意狭窄的夜间任务开始。
不是“管理我的整个公司”。
不是“改进每一个仓库”。
只是调查少量明确批准的 GitHub issue。
以下是我会配置的例程：
Create a routine called Engineering Night Shift.
Schedule:
Every night at 11:00 PM.
Coordinator:
Chief
Input:
GitHub issues labeled "agent-ready"
in the approved repository.
Limit:
Maximum 2 new issues per run.
Process:
1. Check the active task ledger.
2. Skip duplicate or blocked assignments.
3. Research the selected issues.
4. Reproduce the reported failures.
5. Delegate approved implementation work.
6. Run relevant automated checks.
7. Request independent review.
8. Prepare draft pull requests.
9. Save task checkpoints.
10. Generate a morning report.
Stop if:
- Required access is missing
- The issue cannot be reproduced
- The same repair fails twice
- Sensitive changes need approval
- Execution limits are reached
Never merge or deploy automatically.
一次定时运行并不是一个无限、不可阻挡的工作者。
任务可能失败，使用限额可能用尽，工具可能超时，外部状态可能在智能体不活动时发生变化。
这正是任务检查点和恢复规则重要的原因。
目标不是一个永远不会遇到问题的 AI。
而是一个懂得如何报告问题、而不是凭空捏造成功的 AI 运营体系。
## 11. 晨报应该是什么样子
大多数自主智能体的演示聚焦于智能体开始做某事的那一刻。
我更关心它完成之后还剩下什么。
晨报才是真正的产品。
它应该包含每个任务的实际状态和指向支撑产出物的链接。
例如，一次假设性的工程夜班可能产出：
ENGINEERING NIGHT SHIFT
ISSUE #104
Status: REVIEW PASSED
Result: Draft PR prepared
Tests: 18 passed, 0 failed
Approval: Merge required
ISSUE #107
Status: BLOCKED
Result: Bug reproduced
Problem: Missing test credentials
Next: Request approved access
SUMMARY
1 draft PR ready
1 issue blocked
0 production deployments
0 unauthorized changes
这些是示意性结果，并非来自某次实际完成的智能体运行的输出。
但报告结构才是重要的部分。
Chief 不应掩盖失败的任务。
Reporter 不应把尝试过的工作描述为已完成的工作。
而系统永远不应在无法指出实际验证证据的情况下，声称自己验证了某件事。
## 12. 让整个系统更安全的那条规则
有一条原则，我会对每位专家强制执行。
AI 可以准备有影响的操作。
它不会自动获得执行这些操作的许可。
阅读文档、运行测试、准备报告、创建草稿 pull request，可以在定义好的环境中被允许。
合并代码、部署到生产环境、删除记录、更改计费系统以及修改敏感权限，都应要求明确的授权。
这个区别很重要，因为更强大的 AI 模型可以完成更长的操作链。
一个能够推理二十步的智能体，也有更多机会迈向危险的第二十一步。
一个设计良好的系统不需要阻止所有自动化。
它需要决定自主性在哪里结束。
而且这个边界应由实际被访问的系统来强制执行，而不仅仅是在提示词里描述。
## 13. AI 团队应该改进它的流程，而不是重写它的规则
在一次任务完成后，Chief 可以回顾是什么让工作变得缓慢或不可靠。
也许 Researcher 反复遗漏了一个重要的文档文件。
也许 Builder 因为依赖未安装而陷入困境。
也许 Reviewer 在多个改动中发现了同一类型的回归。
这些失败可以转化为可复用的工作流改进。
例如，一个经过验证的设置流程可以成为项目技能。
一个反复出现的代码审查检查可以成为一个测试。
一个常见的任务格式可以成为一个模板。
但智能体不应默默把自己的猜测变成永久规则。
一个提议的改进不是已批准的决策。
一次失败的运行并不自动构成“流程应当重写”的证据。
而从一个项目中获得的有用经验，也不应自动获得对另一个项目的权威性。
记忆系统应保留经过审查的流程，同时把临时观察单独存放。
这样，团队才能变得更一致，而不会对自己的错误更有信心。
## 14. 最初的 24 小时
我不会一开始就创建十个智能体、连接所有账号并启用无人值守执行。
我会从一个完整的工作流开始。
给 Chief 一个低风险的 GitHub issue。
让 Researcher 调查它。
让 Builder 在隔离分支上准备修复。
要求运行真实的测试。
让 Reviewer 检查改动。
然后让 Reporter 产出最终的交接。
如果系统正确完成了这一流程，就把成功的流程保存为可复用的工作流。
在第二个 issue 上再运行一次。
检查结果在一个全新会话后是否仍然可理解。
只有在那之后，才考虑定时夜班。
因为目标不是构建尽可能大的 AI 团队。
而是构建能够可靠完成有意义工作的最小团队。
## 真正的转变
Claude 可以推理难题、编写代码，并帮助产出复杂的技术工作。
Grok Bot 可以协调一个持久的工作环境并自动化支持的任务。
它们共同创造了一个有趣的基础。
但无论是模型智能还是持久化计算机，都不会自动产出一个可靠的员工。
缺失的部分是：责任归属、证据、记忆、权限，以及在出现故障时恢复的方式。
这就是这个架构重要的原因。
Chief 管理结果。
专家各自拥有自己的阶段。
Claude 产出实施工作。
Reviewer 挑战结果。
记忆保留相关决策，而不把过时的观察当作当前真相。
检查点让被中断的工作可以恢复。
审批控制让有影响的操作始终处于人类权威之下。
而晨报会准确告诉你发生了什么。
AI 智能体的未来，不是一个可以不间断工作二十分钟的聊天机器人。
而是一个你可以停止监督数小时，回来时仍能理解、验证和控制的系统。
## 更多我的内容
我撰写关于 Grok Bot、Claude、AI 员工、自主工程、智能体记忆、多智能体编排，以及把 AI 推理转化为已完成工作的实用系统的文章。
关注 @0xkvro 获取更多内容。
往期文章
1. x.com/0xkvro/status/2110395362745651233
2. x.com/0xkvro/status/2108602220014870899
3. x.com/0xkvro/status/2106763188100362388
在你构建下一个拥有世上所有工具、却不知道“完成工作”到底意味着什么的 AI 智能体之前，先收藏这篇吧。
## 相关链接
- [kvro](https://x.com/0xkvro)
- [@0xkvro](https://x.com/0xkvro)
- [14K](https://x.com/0xkvro/status/2113678227096961252/analytics)
- [@0xkvro](https://x.com/@0xkvro)
- [x.com/0xkvro/status/2110395362745651233](https://x.com/0xkvro/status/2110395362745651233)
- [x.com/0xkvro/status/2108602220014870899](https://x.com/0xkvro/status/2108602220014870899)
- [x.com/0xkvro/status/2106763188100362388](https://x.com/0xkvro/status/2106763188100362388)
- [Upgrade to Plus](https://x.com/i/premium_sign_up)
- [1:05 AM · Oct 24, 2026](https://x.com/0xkvro/status/2113678227096961252)
- [14.3K Views](https://x.com/0xkvro/status/2113678227096961252/analytics)
- [View quotes](https://x.com/0xkvro/status/2113678227096961252/quotes)
---
*导出时间: 2026/10/26 09:59:10* 
