核验范围：本文以 mattpocock/skills 官方仓库 的 main 分支为主要来源，阅读了 README.md、.claude-plugin/plugin.json、ADR-0002、grilling、writing-great-skills，并核对了 implement 的流 ...
在上一篇中，我们构建了基于磁盘 Mailbox 的文件消息总线，使 Agent 团队成员之间能够互发消息。
然而，如果消息只是任意的自由自然语言文本，团队很快会在高风险场景中陷入混乱与失控：
强制关机导致数据损坏：Leader 突然发一句“请停止工作退出”，而 Coder 正在写入关键文件，强行退 ...
在第 4 篇中，我们引入了 Subagent（子智能体）。但那时的 Subagent 是一次性的临时工：任务派生出去，子 Agent 执行完毕返回纯文本结论后随即被销毁。它没有持久化的团队身份，不能与其他平级 Worker 交流，更无法支持长期跨会话的多方协同。
当面对庞大的工程重构——例如微服务拆 ...
在真实的软件构建与集成中，命令执行从来都不是瞬时完成的。运行 npm install、跑一套包含数千个用例的 pytest、或者执行一次完整的 docker build，耗时往往需要 2 到 5 分钟甚至更长。
在最原始的 Agent 循环中，工具执行是严格同步阻塞的：
12# 同步阻塞的悲剧：整条 ...
在第 3 篇中，我们通过内存版的 TodoManager 让模型具备了基本的工作清单意识。但随着任务规模从“修改两个函数”升级到“迁移大型模块与微服务”，内存快照的脆弱性暴露无遗：
进程崩溃即前功尽弃：只要终端意外中断或电源故障，整个会话中的任务进度全部归零；
缺乏前置依赖拓扑（DAG）：无法清晰 ...
在真实的软件工程中，一个残酷的物理事实是：上下文窗口终究是有限的。
读取一个包含 1,000 行代码的文件，就会消耗约 4,000 个 Token；在排查大型系统的复杂 bug 时，读取 20 个模块、运行 15 次构建与单测，活跃上下文会轻松突破 100k 甚至 180k Token。如果不对上下 ...
随着 Agent 接入的业务系统越来越复杂，团队往往希望为它注入各种专有知识：代码审查规范、安全审计红线、API 文档模版、数据库变更规范、前端埋点要求等。
很多开发者的第一反应是把所有这些规范全量拼接到 System Prompt（系统提示词）中。然而，这种做法在真实工程中会迅速撞上物理墙：
T ...
在构建自主 Coding Agent 的过程中，一个不可逆的物理规律是：Agent 运行的轮次越多，messages 消息数组就会越发庞大。
设想主 Agent 正在执行重构任务，期间需要确认：“当前仓库采用的单测框架是 jest 还是 vitest？”为了得出这个结论，Agent 可能需要依次读取 ...
核验范围：本文阅读的是 affaan-m/ECC 的 v2.0.0 标签，重点核对 README.md、.claude-plugin/plugin.json、hooks/README.md、skills/continuous-learning-v2/SKILL.md 和 the-shor ...
在掌握了 Agent 核心循环与文件操作工具后，Agent 已经能够完成“读取文件 A 并修复某行报错”这类简单的单步任务。
但一旦进入真实软件工程场景——例如“为系统增加 JWT 鉴权功能”，任务通常涉及读取配置、编写鉴权中间件、修改登录路由、补充单测并更新文档。在多达十几轮的工具调用后，没有规划 ...
