人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载导读本文讲解 openJiuwen agent-core 仓库中面向 AI 编码助手的 Karpathy 式行为准则.claude/rules/karpathy-principles.md。它规定了 Agent 在仓库内编写代码时如何思考与行动的四个核心原则——先思考再编码、简单优先、外科手术式改动、目标驱动执行并配套Makefile中的可验证命令闭环。读完本文你将掌握如何把模糊任务转化为可验证目标、如何利用make test TESTFLAGS...与make check COMMITSN进行精准验证以及在面对仓库内 Card/Config 拆分、Runner.resource_mgr、sandbox 与真实操作双重语义等复杂抽象时避免臆断的具体方法。这套准则在仓库中的定位karpathy-principles.md位于仓库的 .claude/rules/ 目录与architecture.md、code-style.md、git-workflow.md、testing.md、security.md、logging.md、error-codes.md等规则文件并列并由仓库根目录的 AGENTS.md 统一索引。AGENTS.md 明确说明这些共享指令适用于所有在 agent-core 中工作的 AI 编码助手并要求优先参考相邻代码和测试而非臆测Prefer nearby code and tests over assumptions。需要特别强调的是该文档与上述技术规则是互补关系技术规则决定代码应该写成什么样而 Karpathy 式原则管理 Agent 的思维方式与行为方式而非代码本身govern how the agent thinks and acts, not what the code does。它适用于任何语言、任何框架是跨模块、跨任务的行为底座。该准则源自 Andrej Karpathy 对 LLM 编码常见陷阱的系统观察经开源社区整理为可操作的技能清单agent-core 将其吸收为仓库级规则并针对本仓库的具体架构补充了上下文注释。原则一先思考再编码Think Before Coding不要臆测。不要隐藏困惑。显式暴露权衡。在动手实现之前文档要求 Agent 做到四点显式陈述假设把每一个前提假设写出来不确定时宁可提问也不要猜。多义并存时显式呈现如果一个需求存在多种合理解释把它们全部摆出来而不是默默选定一种。发现更简方案要直说如果存在更简单的做法明确提出来并在证据充分时合理地顶回去Push back when warranted。不清楚就停下来指出令人困惑的点然后提问。在 agent-core 语境下为什么先思考尤其重要文档专门为本仓库补充了一条关键警告agent-core 的代码库包含大量复杂抽象其中最典型的是三类Card / Config 拆分Card如AgentCard、ToolCard、WorkflowCard、SysOperationCard定义身份与元数据运行时行为属于 configs、agents、managers 或资源实例。例如 agent_card.py 中的class AgentCard(BaseCard)以及 workflow/base.py、sys_operation/sys_operation.py 中的对应 Card。改动时若不清楚元数据与运行时行为的边界很容易把行为塞进错误的一层。Runner.resource_mgr的进程级共享状态在 runner.py 中Runner是一个单例类resource_mgr: ResourceMgr通过类属性代理到全局 runner 实例统一管理 workflow、agent、agent_team、tool、model、prompt 等资源。它属于进程级共享状态AGENTS.md 要求使用稳定 ID 并保持测试隔离Use stable IDs and keep tests isolated。sandbox / 真实操作双重语义例如 sys_operation/base.py 定义了SANDBOX sandbox边界sys_operation/config.py 中restrict_to_sandbox与sandbox_root字段控制文件系统操作是否被限制在沙箱根目录内另有一些工具既支持沙箱执行也支持真实执行。二者行为模式不同不能默认它们等价。文档给出的指导是当行为存在歧义时不要默默假设它们如何交互而要提问。这本质上是把先澄清、后编码固化为 Agent 的默认行为。原则二简单优先Simplicity First解决该问题所需的最小代码量。不做任何投机性扩展。对应的四条禁止事项非常明确不加任务要求之外的功能不为单次使用的代码引入抽象不增加未被要求的灵活性或可配置性不为不可能发生的场景编写错误处理如果 200 行能写成 50 行就重写。在 agent-core 语境下文档给出的具体场景是新增一个工具tool或护栏rail时优先实现最小可用版本。复杂特性可以增量添加但过度设计的抽象在后期极难移除。文档提供了一个自我审视的检验标准一位资深工程师会说这是过度复杂吗——如果答案是肯定的就简化。从源码结构看这一原则与仓库的分层组织方式相吻合openjiuwen/core/提供基础 SDKopenjiuwen/harness/在其上构建编码智能体框架新增能力通常应先在最小形态落地再通过openjiuwen/extensions/的扩展点增量演进。原则三外科手术式改动Surgical Changes只触碰必须改的部分。只清理自己造成的混乱。编辑既有代码时不要顺手改进相邻代码、注释或格式不要重构没有坏的东西匹配既有风格即使你自己会写得不一样发现无关的死代码时提及它但不要删除它。而当你的改动制造了孤儿orphans时移除你的改动导致的未使用 import / 变量 / 函数除非被要求否则不要移除预先存在的死代码。在 agent-core 语境下文档特别指出deepagents子系统prompts、rails、tools、workspace、tests耦合紧密一处改动常常牵动其他组件——但必须保持专注每一行改动都应能直接追溯到用户请求。这与 AGENTS.md 中优先小而精准的 diff不要机会主义地重构无关区域Prefer small, targeted diffs. Do not refactor unrelated areas opportunistically的指令完全一致。原则四目标驱动执行Goal-Driven Execution定义成功标准。循环验证直到通过。这是四条原则中最具操作性的部分核心动作是把任务转化为可验证的目标。文档给出了一张转化对照表不要这样说转化为加校验为非法输入编写测试然后让它们通过修 bug编写能复现它的测试然后让它通过重构 X确保重构前后测试都通过对于多步骤任务要求先陈述简短计划每个步骤后接一个verify: [check]验证点形成类似下面的结构1. [步骤] → 验证: [检查项] 2. [步骤] → 验证: [检查项] 3. [步骤] → 验证: [检查项]文档解释了这个机制的价值强成功标准让 Agent 能够独立循环推进弱标准如让它跑起来会导致不断需要澄清。这实际上是把验证闭环内化到每一步而不是等到最后统一验收。在 agent-core 语境下的验证命令文档为 agent-core 指定了两条具体命令二者的底层实现均可从仓库根目录的 Makefile 核实make test TESTFLAGS...定向测试。Makefile 第 8 行定义TESTFLAGS ? .默认值为当前目录即全量测试第 162-165 行将其直接透传给pytest$(RUN_CMD) pytest $(TESTFLAGS)。因此make test TESTFLAGStests/unit_tests/core/test_xxx.py等价于只运行指定文件可用于验证目标驱动的第 1 步改动没破坏对应测试。make check COMMITSN提交前风格验证。Makefile 第 47 行定义COMMITS ? 0当COMMITS 0时Makefile 将 diff 范围设为HEAD~$(COMMITS)..检查最近 N 个提交改动的 Python 文件否则默认--cached检查暂存区。check目标第 200-212 行依次串联formatruff 格式、spellingcodespell 拼写、lintruff lint、pylint四道检查。此外仓库还提供了与目标驱动执行直接配套的完整验证管线.claude/skills/verification-loop/SKILL.md把上述命令固化为一个 6 阶段验证技能构建编译 → 类型检查make type-check→ 静态检查make check→ 测试与覆盖率make test→ 安全扫描bandit -r openjiuwen/ -ll→ diff 审查并定义了结构化的验证报告模板供每次有意义的提交前运行。这从工程实践上印证了目标驱动、循环验证在 agent-core 中的完整落地形态。文档还要求执行验证后要把验证结果反馈给用户Return the verification result to the user而不是只说我改完了。适用边界与注意事项本准则面向的是在 agent-core 仓库内工作的 AI 编码助手Agent是行为层面的指导不替代.claude/rules/下的技术规则与 AGENTS.md 中的仓库事实约定。make check/make type-check默认作用于暂存区文件使用前需先git add或通过COMMITSN指定检查最近 N 次提交Makefilehas-staged-changes目标会在无选中文件时报错并提示。验证命令基于uv环境自动选择执行器UVyes时使用uv run否则回退到python -m详见 Makefile 第 88-96 行首次使用前建议先执行make install安装工具链依赖。小结这套 Karpathy 式原则在 agent-core 中的价值可以浓缩为三点先思考澄清而非臆测守住复杂抽象Card/Config、Runner.resource_mgr、sandbox/real 双重语义的边界用最小代码与最小 diff 落地让每一行改动都可追溯到需求用可验证目标驱动执行借助make test与make check形成改动-验证-反馈的闭环。文档最后给出了这套原则是否起效的判据diff 中不必要的改动更少、因过度复杂化导致的返工更少、澄清性问题出现在实现之前而非犯错之后。这套判据同样适用于任何希望把 AI 编码助手从能写代码提升到可靠地交付代码的团队。赞分享人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载相关推荐Karpathy 编码准则用一份 CLAUDE.md 规范 Claude Code 行为的四大原则与实战安装指南Karpathy 编码准则用一份 CLAUDE.md 规范 Claude Code 行为的四大原则与实战安装指南 导读 本文围绕 README.md httpAI 技能提示工程受 Karpathy 启发的 Claude Code 行为指南用四大原则根治 LLM 编码陷阱受 Karpathy 启发的 Claude Code 行为指南用四大原则根治 LLM 编码陷阱 本文基于 README.zh.md https://link.AI 技能提示工程gogcli 管理 Gmail 假期自动回复gog gmail settings vacation update 命令详解gogcli 管理 Gmail 假期自动回复gog gmail settings vacation update 命令详解 本篇指南聚焦 gogcliGooAI 技能提示工程上一篇Poppler Windows 预编译工具链 10 分钟装好并跑通验证下一篇Windows Defender 完整卸载指南10 分钟最快上手步骤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考