在第 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 鉴权功能”，任务通常涉及读取配置、编写鉴权中间件、修改登录路由、补充单测并更新文档。在多达十几轮的工具调用后，没有规划 ...
在上一篇中，我们通过一个极简循环和一个 bash 工具跑通了 Agent 的最小可运行闭环。
在日常使用中，很多人会产生疑问：既然 Bash 本身就是图灵完备的万能工具，直接让大模型通过 cat、sed、echo 完成所有文件操作不就行了吗？为什么专业的 Coding Agent 还要费尽周折地实现 ...
在探讨复杂的自主智能体架构时，我们很容易被多角色对话、规划图、记忆网络等概念裹挟。但如果剥去所有外层的花哨包装，Agent 的物理内核其实就是一个受控的循环语句。
大语言模型本身具备强大的代码推理能力，但它没有双手，碰不到现实世界——它既不能读取磁盘文件，也不能运行单测，更看不到标准错误输出（std ...
