项目快照:shareAI-lab/learn-claude-code,约 74,450 个 Star,12,046 个 Fork;最新推送时间 2026-08-17T06:27:58Z。本文基于仓库公开资料撰写。
项目地址:https://github.com/shareAI-lab/learn-claude-code · https://learn.shareai.run

项目速览(TL;DR)
learn-claude-code 是由 shareAI Lab 发布的 Python 开源项目,项目描述为“Bash is all you need——一个从零构建的、类似 Claude Code 的微型智能体工具框架(agent harness)”。仓库默认分支为 main,采用 MIT License,仓库资料显示有 74,450 个 Star 和 12,046 个 Fork。
项目的核心观点不是通过大量流程编排代码“制造”智能,而是为模型提供可操作的环境。按照 README 的表述,模型负责决策与推理,工具框架负责提供工具、知识、观察结果、动作接口和权限边界;仓库重点因此落在智能体工具框架(agent harness)的工程设计,而不是训练基础模型。
“Agency Comes from the Model. An Agent Product = Model + Harness.”
来源:README
定位与目标用户
该项目定位为面向真实软件工程场景的智能体工具框架学习项目。它关注模型如何在终端、文件系统和其他外部环境中获取信息并执行动作,而不是把多个模型调用简单串接成固定流程。
目标用户应当具备一定的 Python、命令行和模型 API 基础,或者正在研究编码智能体的工具设计、上下文管理、权限控制与任务分解。README 将相关工作概括为“构建智能体运行的世界”,因此读者需要把注意力放在环境接口和运行约束上。
- 希望理解 Claude Code 类编码智能体内部工程抽象的开发者。
- 需要设计文件读写、Shell 执行、API 调用或浏览器控制工具的工程师。
- 研究上下文压缩、子任务、知识加载和权限边界的技术人员。
- 希望以较小代码规模学习智能体工具框架基本构成的学习者。
核心概念:模型与工具框架的分工
README 将智能体产品拆分为模型和工具框架两部分。模型通过训练获得感知、推理和行动能力;工具框架则把模型放进特定环境,为它提供能够观察和改变环境的接口。
这种划分直接影响工程责任边界:工具框架不能替代模型训练,也不应被误认为仅靠规则树、节点图或提示词链就能产生自主能力。项目资料把工具框架抽象为以下五类组成部分。
| 组成部分 | 职责 | 典型输入 | 典型输出或效果 |
|---|---|---|---|
| 工具(Tools) | 提供文件、Shell、网络、数据库或浏览器等动作能力 | 模型生成的工具调用请求 | 命令结果、文件内容或外部系统响应 |
| 知识(Knowledge) | 向模型提供产品文档、架构记录、API 规范和风格指南 | 当前任务所需的领域资料 | 用于推理的上下文信息 |
| 观察(Observation) | 把环境状态反馈给模型 | Git 差异、错误日志、浏览器状态等 | 模型下一轮决策所需的状态描述 |
| 动作接口(Action Interfaces) | 把模型的决策映射到 CLI、API 或界面交互 | 结构化动作或工具参数 | 环境状态发生变化 |
| 权限(Permissions) | 限定文件访问、破坏性操作和外部系统信任边界 | 路径范围、审批要求或隔离策略 | 允许、拒绝或请求人工确认 |
核心功能
从 README 可确认的功能重点是工具、知识、上下文、权限和轨迹数据的工程组织。仓库资料没有提供完整的 Python 模块清单或每个接口的函数签名,因此下述内容描述项目明确提出的设计职责,不把未公开的实现细节当作事实。
工具调用与环境动作
工具是模型与外部环境之间的动作边界。模型提出读取文件、写入文件、执行 Shell、调用 API、访问浏览器或查询数据库等请求,工具框架负责将请求转换为实际动作,并把结果返回到后续上下文中。
工具设计的关键不是工具数量,而是动作是否原子、可组合且描述清晰。README 明确建议工具具有原子性、可组合性和清晰描述;至于仓库当前版本具体实现了哪些工具,官方仓库资料未提供完整清单,建议以最新 README 和源码为准。
知识按需加载
知识模块用于承载产品文档、架构决策记录、领域参考资料、API 规范和编码风格要求。README 提出应按需加载知识,而不是在任务开始时无条件把所有资料放入上下文,这一原则有助于控制上下文内容与任务目标之间的相关性。
当前资料没有说明知识文件的目录、索引格式、检索方式或更新机制。因而不能据此推断项目使用了向量数据库、全文搜索或某一种检索增强生成(Retrieval-Augmented Generation,RAG)实现。
上下文管理与子任务
README 提到,子智能体(subagents)可以在独立消息列表中处理聚焦任务,上下文压缩(context compaction)可以缩短较早的历史消息,任务系统则可以使目标超出单次对话的生命周期。它们共同解决长任务中的信息膨胀和任务状态持续问题。
资料没有公开子智能体的创建语法、上下文压缩触发阈值、任务持久化介质或消息协议。使用者不应根据这些概念自行假设某个具体 API 已经存在,实际行为需要以仓库源码和最新文档为准。
权限与审批边界
权限模块负责限制智能体能够访问和改变的环境。README 举出的边界包括文件系统沙箱、破坏性操作审批,以及智能体与外部系统之间的信任边界。
这意味着工具执行不应被视为天然可信的函数调用。对于删除文件、修改大量代码、访问外部服务或执行不可逆操作,应在部署设计中明确路径限制、人工确认和隔离环境;仓库资料没有提供具体沙箱实现或默认审批策略。
轨迹数据与后续训练
工具框架执行的每一条感知、推理和动作序列,都可以成为后续模型改进的训练信号。README 将真实部署中的轨迹数据视为下一代智能体模型微调的重要原材料。
这是一种数据工程方向,而不是仓库已经提供训练流水线的证明。资料没有说明轨迹数据的采集格式、脱敏方式、保存位置、保留周期或训练脚本,不能据此宣称项目具备完整的模型训练能力。
系统架构与关键模块
从公开描述看,项目的架构中心是“模型—工具框架—环境”的闭环:模型产生决策,工具框架执行动作并整理观察结果,外部环境返回新的状态。该架构可以帮助读者分析代码,但不能替代对实际源码模块的核验。
# 以下是依据 README 概念整理的架构示意,不是仓库已确认的接口签名。
model_output = model.decide(context)
action_result = harness.execute(
tools=tools,
action=model_output,
permissions=permissions,
)
context = harness.observe(
result=action_result,
knowledge=knowledge,
)在职责划分上,模型适合负责任务理解、步骤规划和结果判断;工具框架适合负责动作注册、参数传递、结果回收、权限校验和上下文组织;环境则包括代码仓库、终端、文件系统或其他获授权的服务。根据本文作者的经验判断,这种边界比把所有逻辑写入固定分支更便于测试和替换模型,但具体收益仍取决于实现质量。
官方仓库资料未提供具体的模块名称、类层级、调用时序图、进程模型、并发模型或数据持久化方案。需要进行二次开发的团队应先检查默认分支 main 的实际目录和源码,再决定扩展点。
依赖与运行环境
已知运行语言为 Python,模型接入配置面向 Anthropic 兼容接口。资料明确给出了 Anthropic API 密钥、模型标识和可选基础 URL,但没有给出 Python 版本、操作系统要求、第三方依赖列表、安装方式、入口文件或容器配置。
- 语言:Python。
- 默认分支:
main。 - 模型服务:默认配置示例为 Anthropic 兼容接口。
- 默认模型标识:
claude-sonnet-4-6。 - 可选服务商:资料列出 Anthropic、MiniMax、GLM、Kimi 和 DeepSeek 的兼容配置。
- 端口、进程管理方式和部署拓扑:官方仓库未提供该信息,建议以最新 README 为准。
不能从“语言:Python”这一仓库元信息推导出具体 Python 版本,也不能推导出项目使用了某个 Web 框架、命令行框架或异步运行时。部署前应将这些内容作为环境核验项,而不是默认值。
快速开始:配置、运行与验证
资料能够确认配置字段,但没有提供安装命令、启动命令、入口脚本或验证命令。因此,下面只给出可由 .env.example 直接核对的最小配置示例,不虚构一个仓库中未出现的运行入口。
第一步:准备配置文件内容
# .env.example 中给出的配置字段
ANTHROPIC_API_KEY=<你的-API-KEY>
MODEL_ID=claude-sonnet-4-6
# 可选:使用 Anthropic 兼容服务商时填写
# ANTHROPIC_BASE_URL=https://api.anthropic.com<你的-API-KEY> 仅是占位符,不应替换为公开粘贴的真实密钥。README 资料未给出“复制环境文件”“安装依赖”或“启动程序”的官方命令,因此不能把 cp .env.example .env、pip install 或某个 python 启动命令写成项目的已确认用法。
第二步:安装与运行信息核验
安装方式、依赖文件名称、可执行入口和运行参数均未出现在所给资料中。官方仓库未提供该信息,建议以最新 README、仓库文件列表和官网文档为准;在完成核验前,不应直接在生产主机执行未知启动命令。
第三步:验证最小闭环
可确认的验证条件只有配置层面:密钥字段存在、模型字段使用资料列出的模型标识、基础 URL 与目标兼容服务商一致。应用层的“成功启动”“完成一次工具调用”或“返回模型响应”验证命令,官方仓库资料未提供,不能给出伪造的输出示例。
因此,本节无法在不引入未证实命令的前提下提供完整的“安装 → 运行 → 验证”可执行闭环。发布或部署时应补充最新仓库明确给出的命令,并同时记录 Python 版本、依赖版本和模型服务访问条件。
配置说明
.env.example 是资料中唯一明确提供的配置样例。下表区分必填字段、可选字段和服务商配置组合;同名字段的多行值来自样例中的不同服务商段落,不代表可以同时设置多个值。
| 字段名 | 类型 | 默认值 | 作用 |
|---|---|---|---|
ANTHROPIC_API_KEY |
字符串 | 未提供 | 访问模型服务所需的 API 密钥,样例标记为 required |
MODEL_ID |
字符串 | claude-sonnet-4-6 |
指定模型标识,样例标记为 required |
ANTHROPIC_BASE_URL |
URL 字符串 | https://api.anthropic.com |
指定 Anthropic 兼容接口的基础 URL,可选 |
ANTHROPIC_BASE_URL(MiniMax 国际配置) |
URL 字符串 | https://api.minimax.io/anthropic |
将请求指向样例列出的 MiniMax Anthropic 兼容端点 |
ANTHROPIC_BASE_URL(GLM 配置) |
URL 字符串 | https://api.z.ai/api/anthropic |
将请求指向样例列出的 GLM Anthropic 兼容端点 |
ANTHROPIC_BASE_URL(Kimi 配置) |
URL 字符串 | https://api.moonshot.ai/anthropic |
将请求指向样例列出的 Kimi Anthropic 兼容端点 |
ANTHROPIC_BASE_URL(DeepSeek 配置) |
URL 字符串 | https://api.deepseek.com/anthropic |
将请求指向样例列出的 DeepSeek Anthropic 兼容端点 |
服务商对应的 MODEL_ID 也由样例列出,包括 MiniMax-M3、glm-5.2、kimi-k2.7-code、deepseek-v4-pro 和 deepseek-v4-flash 等。模型可用性、价格、区域访问条件和当前接口状态,资料要求以各服务商文档为准,本文不对其作额外承诺。
进阶用法
进阶使用的重点是围绕任务环境设计工具,而不是盲目增加提示词或流程节点。README 提供的方向包括按需加载知识、使用子智能体分隔工作上下文、通过上下文压缩控制历史长度,以及用任务系统保存跨对话目标。
按领域拆分工具
编码场景可以把文件读取、文件写入、Shell 执行和错误观察视为不同动作接口。每个工具应明确输入、输出和权限边界,使模型能够根据当前状态选择动作;资料没有给出工具注册格式,因此这里只能说明设计原则。
将长任务拆为聚焦子任务
当任务包含代码阅读、实现、测试和错误修复等不同阶段时,可依据 README 的子智能体概念将聚焦工作放入独立消息列表。这样做的目标是减少无关历史对当前任务的干扰,而不是暗示项目已经提供固定的子智能体编排命令。
把任务目标从对话中分离
任务系统的价值在于让目标不依赖单次会话历史。具体是使用文件、数据库还是其他存储,官方资料未说明;在实现时应明确目标状态、完成条件、失败状态以及人工接管方式。
可观测性与运维
公开资料没有提供日志格式、指标名称、链路追踪、重试策略、成本统计、健康检查、并发限制或服务级别协议(SLA)。因此,本项目不能依据现有资料被描述为具备某种生产级可观测性或稳定性承诺。
在授权测试环境中,运维记录至少应能关联一次模型请求、工具动作、工具结果和最终任务状态。对于文件修改和 Shell 执行,还应保存审批结果与错误日志;这些是部署治理建议,不是仓库已经实现的功能。
- 记录模型标识和使用的兼容服务商端点,但避免记录完整 API 密钥。
- 区分模型响应错误、工具执行错误、权限拒绝和环境资源错误。
- 为破坏性动作保留人工审批记录和可恢复信息。
- 在测试环境先验证超时、重复调用和上下文过长等失败路径。
官方仓库未提供端口、部署清单、备份策略、告警阈值或升级流程,建议以最新仓库资料为准。
安全与合规边界
该项目涉及模型调用、Shell、文件系统和外部工具等潜在高权限能力,安全边界应由部署者主动建立。本文只讨论获得授权的本地、测试或企业内部环境,不提供面向未授权目标的攻击、绕过检测或凭据窃取方法。
凭据与隐私
API 密钥应通过受控的环境变量或密钥管理机制注入,不应提交到 Git 仓库、日志或模型上下文。代码、日志、产品资料和工具返回结果可能包含个人信息、商业秘密或访问令牌,使用轨迹数据进行分析或训练前必须完成授权、脱敏和访问控制。
执行隔离
Shell、文件写入和网络请求应限制在明确授权的目录、服务和测试账号内。对删除、覆盖、外发数据或修改系统状态的动作,应设置人工审批、最小权限和可恢复措施;资料只提出这些设计方向,没有说明仓库提供了哪一种沙箱或审批实现。
服务商与跨区域访问
.env.example 列出了多个 Anthropic 兼容服务商及国际、China mainland 配置。实际选择端点时,应核验数据处理区域、合同条款、保留政策和组织合规要求;项目资料没有提供这些服务商的法律或隐私承诺。
许可证与商用条款
仓库使用 MIT License,版权信息为 Copyright (c) 2024 shareAI Lab。MIT License 授予获得软件者使用、复制、修改、合并、发布、分发、再许可和销售软件副本的许可,但必须遵守许可证文本中的条件。
- 分发软件或其重要部分时,应保留版权声明。
- 应保留 MIT License 的许可和免责声明文本。
- 许可证明确声明软件按“现状”提供,不提供适销性、特定用途适用性和不侵权保证。
- 许可证限制了作者对因使用软件产生的索赔、损害或其他责任承担范围,具体以仓库 LICENSE 为准。
从 MIT License 的授权范围看,商业使用在许可允许范围内可行,但模型服务商的 API 条款、密钥使用规则、数据处理要求和部署所在地法规仍需单独核验。项目本身没有提供商业支持、SLA、赔偿或合规认证承诺,相关事项应以仓库 LICENSE、服务商条款和组织内部审查结果为准。
局限性与已知限制
当前提供的仓库资料主要是 README 的设计理念、LICENSE 和环境变量样例,无法支撑对实现完整度、性能和生产可用性的结论。以下限制是资料缺口或明确边界,不应被解读为未经源码验证的缺陷清单。
- 未提供 Python 版本和完整依赖清单。
- 未提供安装命令、启动命令、入口文件和最小可运行程序。
- 未提供工具、子智能体、上下文压缩和任务系统的具体 API。
- 未提供端口、并发级别、延迟、吞吐量、成本或 Benchmark 数据。
- 未提供日志、指标、追踪、重试和故障恢复的实现说明。
- 未提供默认沙箱、权限策略、网络策略或审计格式。
- 模型标识、兼容端点的可用性和区域访问条件可能受服务商实际状态影响,资料要求以服务商文档为准。
官方仓库未提供该信息,建议以最新 README、官网文档和默认分支源码为准。任何将概念性描述直接转化为稳定接口、性能指标或安全承诺的做法,都需要额外的源码和测试证据。
适合谁
该项目更适合作为编码智能体工具框架的学习和研究入口,而不是在缺少运行资料核验的情况下直接当作生产平台。以下信号有助于判断是否匹配。
- 团队正在使用 Python,并希望研究模型与命令行、文件系统之间的动作接口。
- 任务规模以代码仓库级别的读取、修改、错误观察和任务拆分为主。
- 能够自行管理 Anthropic 或兼容服务商的 API 密钥、模型选择和数据授权。
- 接受阅读源码并补充安装、运行、日志和隔离方案,而不是要求现成的企业运维手册。
- 关注工具原子性、上下文管理、权限审批和轨迹数据,而不只是提示词模板。
不适合谁
如果使用场景要求所有运行参数、合规证据和生产运维能力都已由项目直接提供,则现有资料不足以证明该项目满足要求。以下情况应谨慎选择,或先完成源码、测试和许可证审查。
- 需要明确 SLA、审计报告、CVE 响应流程、厂商支持或长期维护承诺的生产团队。
- 需要固定端口、容器编排文件、健康检查、监控指标和高并发性能数据的服务平台。
- 处理大量个人信息、受监管数据或跨境数据,却无法单独审查模型服务商条款的组织。
- 希望不经人工审批就让模型修改生产文件、执行高权限 Shell 或访问外部系统的使用者。
- 只接受完整图形化产品或稳定公共 API,而不愿意核对仓库源码和最新文档的团队。
常见问题与排查(FAQ / Troubleshooting)
本节只回答资料能够支持的问题;对于仓库没有公开的入口和错误码,不会给出虚构的故障诊断命令。
Q:项目默认使用哪个模型?
A:.env.example 中的默认示例为 MODEL_ID=claude-sonnet-4-6。模型是否对当前账号、区域和服务商可用,需要以对应服务商文档和实际配置为准。
Q:必须设置哪些环境变量?
A:样例将 ANTHROPIC_API_KEY 和 MODEL_ID 标记为 required;ANTHROPIC_BASE_URL 标记为 optional。密钥值没有官方默认值,不能使用样例中的 sk-ant-xxx 作为真实凭据。
Q:如何切换到兼容服务商?
A:根据样例,同时调整 ANTHROPIC_BASE_URL 和 MODEL_ID,并核验服务商的当前模型标识。例如样例列出了 MiniMax、GLM、Kimi 和 DeepSeek 的端点与模型组合。具体可用性、价格和区域限制不由该配置样例保证。
Q:运行时报“找不到启动命令”怎么办?
A:所给资料没有提供启动命令、入口文件或安装步骤,因此无法依据资料判断正确命令。应先检查最新 README 和源码中的入口定义,不要用猜测的模块名替换运行命令。
Q:是否有性能或并发基准?
A:所给资料没有提供性能、规模、延迟、吞吐量或并发基准。部署决策不能使用 Star、Fork 数量替代技术性能测试。
Q:出现模型服务请求失败时如何排查?
A:先检查 API 密钥是否真实且未泄露,再核对 MODEL_ID、ANTHROPIC_BASE_URL 与目标服务商的当前文档是否一致。若仍无法定位,由于资料未给出错误码、重试规则和日志格式,应以服务商响应和仓库最新实现为准。
项目地址与资源
以下链接均来自项目元信息、README 或环境配置样例。服务商链接用于核验 API、模型可用性、价格和区域访问条件,不代表项目对其提供背书。



