Taku
你在 Taku 里生成出来的所有东西，不管是 Agent、工具还是纯软件脚本，底层共享一套统一的通讯协议，可以相互调用。
Harness
Agent Harness 是包裹在 AI 模型外面的那一整层软件基础设施，负责管理模型的生命周期、上下文、工具调用、状态持久化和错误恢复
模型提供推理能力，Harness 提供推理之外的一切
LangChain 的文章里有一个说法：模型是 CPU，上下文窗口是内存，Agent Harness 就是操作系统
三层 Harness
第一层：Runtime
当我们从github中拉取项目A的时候，这个项目有数据库，Redis
我们现在Taku上做了一个视频剪辑APP，项目B
现在我们堆Taku说，把B项目的视频生成skil拼接到A中，这样A就有了视频功能
Taku 的 Runtime 想解决的就是这个环节。生成完直接能跑，跑完直接能用
第二层：统一的后端通讯协议
在 Claude Code 或者 OpenClaw 里面，情况也类似。你生成了三个项目，三个项目的后端是各自独立的。你想让项目 A 调用项目 B 的能力，需要自己手动配置
OpenClaw 的 skill 体系能做的事情也是有边界的，很多投资人以为 skill 什么都能做，实际上限制不少
Taku 定了一套 Protocol：所有在 Taku 生态内生成出来的东西，后端都有一套统一的对 agent 接口
不管它是一个 Multi-agent 系统、一个纯软件脚本、还是一个 AI skill，主 Agent 都可以无缝调用
第三层：跨应用的 context 和记忆共享
你在某个应用里积累的数据、使用习惯、定义的规则，会自动同步给所有相关的应用
AI加快开发流程的内循环外循环
要点速览：
- AI 编码工具加速了开发者的**"内循环"** （写代码、调试），但代码审查、CI/CD、部署等**"外循环"**没有改善，整体交付速度提升有限
- 代码产出增加但审查流程没跟上，等于往堵塞的管道里灌更多水
- 组织流程债务（不再产生价值的会议、签批、旧流程）在 AI 时代变得格外刺眼
- 100% 的 AI 工具采用率 + 0% 的交付改善，完全可能发生
- Forsgren 给 CTO 的建议：追踪 Developer Flow，减少开发者被打断的频率
内循环是开发者个人的工作：写代码、跑本地测试、调试。AI编码这类工具在这个环节效果很好，确实加速了个人编码效率。
但写完代码之后呢？代码要进入审查队列等人来看，要过 CI/CD 流水线（自动化构建和测试的系统），要跑安全扫描，最后才能部署到生产环境。这就是外循环。
AI 加速的是内循环，但真正的瓶颈在外循环；工具采用率不等于价值交付；度量开发者体验，而不只是度量代码产出。
Qclaw
腾讯的openclaw小龙虾
一个方便的小龙虾，现在每天有1000万token，方便我们学习
其内置了许多方便的通道
.claude/文件夹剖析
.claude文件夹是控制Claude在项目中运行行为的核心中枢。其中存放着你的指令、自定义命令、权限规则，还有Claude在各会话中留存的记忆。只要弄清楚各类文件的存放位置和用途，你就能按照团队需求，量身配置Claude Code的运行模式。
两个文件夹
第一个位于你的项目内部，第二个位于你的主目录中
项目级文件夹保存团队配置。你将其提交到git。团队中的每个人都能获得相同的规则、相同的自定义命令和相同的权限策略。
全局的~/.claude/文件夹保存着你的个人偏好和机器本地状态，如会话历史和自动记忆。
CLAUDE.md：Claude的使用手册
这是整个系统中最重要的文件。当你启动Claude Code会话时，它读取的第一个文件就是CLAUDE.md。它会直接将其加载到系统提示中，并在整个对话过程中牢记于心。
简单来说：无论你在CLAUDE.md中写什么，Claude都会遵循。
在项目根目录下的CLAUDE.md是最常见的设置。但你也可以在~/.claude/CLAUDE.md中设置一个用于全局偏好设置，这些设置将适用于所有项目，甚至可以在子目录中设置一个用于特定文件夹规则的CLAUDE.md。Claude会读取所有这些文件并将它们合并。
要写：
- 构建、测试和代码检查命令（npm run test、make build等）
- 关键架构决策（"我们使用带有 Turborepo 的单仓库"）
- 非显而易见的陷阱（"TypeScript严格模式已开启，未使用的变量会被视为错误"）
- 导入约定、命名模式、错误处理风格
- 主要模块的文件和文件夹结构
不要写:
- 任何属于代码检查器或格式化器配置的内容
- 你已经可以链接到的完整文档
- 解释理论的长段落
保持CLAUDE.md文件行数不超过200行。超过这个长度的文件会占用过多上下文，Claude遵循指令的能力实际上会下降。
用于个人自定义设置的 CLAUDE.local.md 文件
在项目根目录中创建 CLAUDE.local.md 文件。Claude 会连同主文件 CLAUDE.md 一并读取该文件，且该文件会被自动纳入Git忽略列表，确保你的个人设置不会提交到代码仓库中。
rules/文件夹：可扩展的模块化指令
LAUDE.md 适用于单个项目。但随着团队规模扩大，你的 CLAUDE.md 文件会变成 300 行的大文件，无人维护，也没人查看。
rules/ 文件夹可以解决这个问题。
.claude/rules/ 目录下的所有 Markdown 文件都会与你的 CLAUDE.md 一同自动加载。你无需使用一个庞大的文件，而是可以按照业务范畴拆分指令：
.claude/rules/
├── code-style.md
├── testing.md
├── api-conventions.md
└── security.md核心优势在于路径限定规则。在规则文件中添加一段YAML前置元数据，该规则便仅在Claude处理匹配文件时生效
commands/ 文件夹：用于存放自定义斜杠命令
开箱即用，Claude Code 有内置的斜杠命令，如 /help 和 /compact。commands/ 文件夹允许你添加自己的命令。
.claude/commands/ 中的项目命令会被提交并与团队共享。如果希望命令不受项目限制、在所有场景中生效，请将其放置在 ~/.claude/commands/ 目录下，这类命令会以 /用户:命令名称 的形式展示。
实用的个人命令示例：每日站会辅助命令、按照自定义规范生成提交信息的命令、快速安全扫描命令。
skills/文件夹：按需使用的可复用工作流
技能是Claude可以自行调用的工作流程，当任务与技能描述匹配时，无需你输入斜杠命令。命令等待你的操作，而技能则会观察对话，并在时机合适时采取行动。
每个技能都存放在其自己的子目录中，并配有一个SKILL.md文件：
.claude/skills/
├── security-review/
│ ├── SKILL.md
│ └── DETAILED_GUIDE.md
└── deploy/
├── SKILL.md
└── templates/
└── release-notes.mdagents/文件夹：专门的子agent角色
当一项任务足够复杂，需要专业专家来处理时，你可以在.claude/agents/中定义一个子代理角色。每个代理都是一个markdown文件，有自己的系统提示、工具访问权限和模型偏好：
.claude/agents/
├── code-reviewer.md
└── security-auditor.mdsettings.json：权限和项目配置
.claude/ 目录下的 settings.json 文件控制着 Claude 被允许和不被允许做的事情。在这个文件中，你可以定义 Claude 可以运行哪些工具、可以读取哪些文件，以及在运行某些命令之前是否需要询问。
一个实用的入门设置
步骤1. 在Claude Code中运行 /init。它会通过读取你的项目生成一个初始的CLAUDE.md文件。将其编辑精简至要点。
步骤2. 添加.claude/settings.json 文件，并根据你的技术栈添加合适的允许/拒绝规则。至少要允许运行命令，拒绝读取.env 文件。
步骤3.为你最常执行的工作流程创建一两个命令。代码审查和问题修复是不错的起点。
步骤4. 随着项目的发展，CLAUDE.md文件变得拥挤时，开始将指令拆分为.claude/rules/文件。在合理的情况下，按路径对其进行范围界定。
步骤5. 添加一个 ~/.claude/CLAUDE.md 文件，其中包含你的个人偏好。这可能是类似 "总是在实现之前编写类型" 或 "更喜欢函数式模式而非基于类的模式" 这样的内容。