从 Claude Code 到 AI 产品架构
我拆开的不是一个 coding 工具，
而是一套 AI 产品如何组织输入、工具、状态、权限与协作的工程方法。
system / messages / tools -> context -> control -> runtime -> multi-agent
Architecture system messages tools context control runtime multi-agent
模型看到的世界，其实很小
再复杂的 harness，最终也只是把信息塞进 system、messages 和 tools。
AI 产品经理设计的不是页面流程本身，而是模型能看到什么、不能看到什么，以及能选择哪些行动入口。
response = client.messages.create(
system=SYSTEM,
messages=messages,
tools=TOOLS,
)不是固定流程，而是动态控制流
Agent 产品不是固定 workflow，而是模型驱动的动态控制流。
产品职责从编排固定步骤，转向设计可控的行动空间。
while True:
response = call_model(messages, tools)
if response.stop_reason != "tool_use":
return response
results = run_tools(response.content)
messages.append(tool_results(results))工具不是按钮，是给模型看的能力接口
工具不是功能按钮，而是模型可理解、可选择、可调用的能力接口。
功能要同时面向人类用户和模型：人要结果，模型要清晰的名称、description、参数边界和失败反馈。
tools = [{"name": "read_file", "description": "..."}]
output = TOOL_HANDLERS[block.name](**block.input)上下文怎么进出，决定产品上限
Subagent、Skill、Compact 看似是不同模块，本质都在解决同一个问题：上下文怎么进、怎么出、怎么被压缩。
关键不是让模型知道更多，而是让它每次只看到足够完成当前任务的最小上下文。
独立 sub_messages，只把摘要回传父 agent。
system prompt 放目录，tool result 按需加载全文。
超限后用摘要替换历史 messages。
把控制权交给模型后，必须加控制层
一旦让模型决定下一步，产品就必须设计权限、拦截、恢复和观测。
AI 产品不能只设计模型能做什么，还要设计什么时候不能做、被拦后如何知道、失败后如何继续。
permission 拒绝危险调用，并把原因回写。
hook 在固定时机审计、提醒或阻止。
recovery 按截断、超限、网络抖动分别恢复。
把一次聊天，变成持续工作系统
真正可用的 AI 产品必须把一次对话升级为可持续推进的工作系统。
任务不只是聊天里的待办项，而应该有生命周期、依赖关系、执行槽位和时间触发机制。
会话内计划草稿。
落盘的持久目标和依赖图。
慢命令后台运行，完成后通知主循环。
未来时间自动注入一条 user message。
多 agent 是系统设计，不是多开模型
多 agent 的核心不是同时调用多个模型，而是角色、状态、通信、协议、执行隔离和外部能力接入。
先设计组织结构和协作协议，再谈模型数量。
teammate 长期存在，有自己的 messages 和 inbox。
protocol 用 request id 和状态机追踪协作。
worktree 为并行任务提供隔离目录。
我的 AI 产品架构框架
从 Claude Code 源码中，可以抽象出一套可迁移的 AI 产品架构框架。
输入层、工具层、上下文层、控制层、运行时层，构成我看 AI 产品的基础地图。
这套方法，后来落到我自己的系统里
Personal Knowledge Harness 不是凭空来的，而是这套 AI 产品架构方法在个人工作系统上的一次落地。
AI 产品的真正设计对象，不是模型本身，而是模型周围那套让它可靠工作的环境。
三层知识库与 context-pack。
能力层、加载规则、入库门禁。
skill 工作流、复盘、计划。
Claude、Codex、OpenClaw 共用记忆。