你不知道的 Agent：原理、架构与工程实践

哈喽大家好我是蝈蝈。最近看到一篇质量相当高的技术长文作者 Tw93把 Agent 的底层逻辑从头梳理了一遍从控制流、上下文工程、工具设计一直讲到多 Agent 协作、评测和安全干货密度很高。我把里面最核心的判断和Agent工程经验整理出来分享给大家。Agent 到底是怎么跑起来的很多人觉得 Agent 很神秘但它的核心循环其实极其简单**感知 → 决策 → 行动 → 反馈**不断重复直到模型返回纯文本为止。整个逻辑抽象出来不到 20 行代码而且这个主循环几乎不会变不管是加子 Agent、加上下文压缩还是加 Skills 加载新能力都是叠在循环外面不动循环本身。这里有一个经常被混淆的概念值得说清楚**Workflow 和 Agent 的本质区别在于控制权在谁手里。**执行路径由代码预先写死的是 Workflow由 LLM 动态决定下一步的才是 Agent。现实中很多打着 Agent 旗号的产品深入看其实更接近 Workflow但这本身没有高下之分关键是给任务找到更合适的解法。Harness 比模型本身更关键这是原文里最反直觉的一个判断也是我觉得最有价值的一条。**Harness 是围绕 Agent 构建的测试、验证与约束基础设施**至少包括四部分验收基线、执行边界、反馈信号、回退手段。有一个非常真实的案例**3 个工程师用 5 个月写了百万行代码提了将近 1500 个 PR是传统开发速度的 10 倍。**这个速度背后不是模型有多强而是几个工程决策做对了约束编码化而非文档化写进 Linter 和 CI 的规则才有执行力写在文档里的规范很容易被忽略Agent 端到端自主完成任务查日志、查指标、复现 Bug、开 PR、处理 Review 反馈、自主合并全链路不需要人介入测试偶发失败用重跑处理而不是阻塞进度。真正决定 Agent 系统能不能收敛的往往不是模型能力而是任务有没有机器可执行的验收标准。任务越清晰、验证越自动化Agent 越能发挥价值任务模糊又没有自动验证Agent 基本只会原地打转。Harness 要做的就是把任务从「模糊人工」推向「清晰自动化」。图里用任务清晰度和验证自动化程度把任务分成四种状态右上角目标明确、结果可以自动验证是最适合 Agent 发挥的区域左上角任务清楚但验收还得人盯吞吐量天花板是人的审查速度右下角有自动化反馈但目标模糊系统会高效地往错误方向跑左下角两者都缺Agent 基本起不到作用。Harness 要做的就是把任务推进右上角让对错有机器可以执行的判断标准而不是靠人盯。上下文工程防的是 Context RotTransformer 的注意力复杂度是 O(n²)**上下文越长关键信号越容易被噪声稀释。**实践中最常见的失效模式是无关内容一旦占到上下文的大头Agent 的决策质量就会明显下滑这个现象叫 Context Rot。很多看起来像模型能力不足的问题追根溯源其实是上下文组织不当。解决方案是**按信息的使用频率和稳定性分层管理**常驻层只放身份定义、项目约定、绝对禁止项保持短、硬、可执行Skills 和领域知识按需加载不用的不占位置当前时间、渠道 ID、用户偏好这类动态信息每轮按需拼入跨会话经验写入 MEMORY.md需要时才读取确定性逻辑完全不进上下文交给 Hooks 或代码规则处理。Skills 的按需加载有一个数据很说明问题**Skill 描述里没有反例时准确率从基准 73% 掉到 53%加上反例后升到 85%响应时间还降了 18.1%。**反例不是可选项是 Skill 描述能不能起作用的关键。工具设计问题多数不在数量不够上下文决定模型能看到什么工具决定模型能做什么。工具定义的质量比数量更关键。仅 5 个 MCP 服务器就可能带来约55,000 tokens的工具定义开销相当于在 200K 上下文里还没开始对话就用掉了近三成。工具设计大致经历了三代演进。第一代是直接把 API Endpoint 封装成工具粒度过细第二代是 ACIAgent-Computer Interface工具应对应 Agent 的目标而不是底层 API 操作比如不要分别暴露create_file、write_content、set_permissions而是直接给一个create_script(path, content, executable)一次搞定第三代是在工具设计之上进一步优化发现、调用和描述方式——动态工具发现可以让上下文保留率达到 **95%**模型准确率从 **49% 提升到 74%**每个工具附带 1~5 个真实调用示例后工具调用准确率可从72% 提升到 90%。调试 Agent 时应该先检查工具定义大多数工具选择错误的原因出在描述不准确不在模型能力。好的工具设计有三个原则参数清晰有约束、错误结构化给出修正建议、定义和实现绑在一起。记忆系统四层分工Agent 不具备原生的时间连续性会话结束后上下文随之清空记忆层得单独设计。按 Agent 实际要解决的问题来分大概有四种记忆上下文窗口工作记忆当前任务最小信息、Skills程序性记忆操作流程和领域规范、JSONL 会话历史情景记忆磁盘持久化支持跨会话检索、MEMORY.md语义记忆Agent 主动写入认为重要的事实每次启动时注入系统提示。左侧是 Agent 运行时只有上下文窗口存在于 messages[] 中会随着会话结束一起清空右侧是磁盘上的持久层Skills 文件按需加载JSONL 会话历史保留完整过程并支持检索MEMORY.md 则沉淀 Agent 主动写入的稳定事实并在后续会话中持续注入。值得一提的是**对大多数 Agent 来说记忆库规模并不需要一开始就引入向量存储**结构化 Markdown 加关键词搜索已经具备足够好的可调试性和成本表现只有当规模超过几千条、并且确实需要语义相似度检索时再考虑引入向量检索才合适。记忆整合的触发时机同样重要当 token 使用量超过上限的50%时自动触发整合成功路径把摘要追加到 MEMORY.md失败路径把原始消息写入 archive 保留完整历史。最关键的不是摘要写得多漂亮而是流程本身必须可回退系统只移动指针不删除原始消息。多 Agent协议先于协作一说到多 Agent很多人先想到并行但工程上要先解决的其实是隔离和协作。多 Agent 的主要价值不是多开几个模型而是**把人的持续参与变成对工件的最终审核。**主 Agent 作为 Orchestrator 统筹全局子 Agent 独立并行工作通过 JSONL inbox 协议通信用 Worktree 隔离文件修改用任务图管理依赖关系。子 Agent 执行完只回传摘要搜索和调试细节留在自己的上下文里不污染主 Agent。有一个风险需要特别注意**多个 Agent 频繁互动时错误会被一层层放大。**Agent A 先带偏Agent B 跟着强化Agent C 再叠加最后所有 Agent 都收敛到同一个高置信度的错误结论。交叉验证能打断这条链让某个 Agent 独立判断而不是顺着前面的结论继续走。评测先修评测再改 Agent这是另一个非常重要的判断。看到 Agent 表现下降不要立刻着手修改 Agent 本身先确认评测系统没有先出问题。评测出了问题你拿到的是一个失真的信号基于它去改 Agent改的方向可能从一开始就是错的。两个核心指标用途不同不能混用Passk适合在开发阶段回答「这个 Agent 理论上能不能做到」Pass^k适合在上线前回答「已有功能有没有被改坏」。评测体系不用等完整了再开始**20 到 50 个真实失败案例就够启动。**有一条判断标准值得记住如果两个领域专家拿同一个案例独立判断结论不一致说明验收标准还没写清楚先解决定义再收集数据。评测系统常见的出错来源运行环境资源不足导致进程被杀、评分器本身有 bug 把正确答案判成失败、测试用例和生产场景脱节。这些问题在表现上和模型退化一模一样很难从结果数字上直接区分。看到评测分数下降先查环境再动 Agent。最后说一句这篇文章给我最大的感触是Agent 工程的核心矛盾不是模型不够强而是外围工程没跟上。Harness 质量、上下文组织、工具描述精度、评测可靠性这些软基础设施的投入回报往往比换一个更贵的模型更高、更稳定。换句话说与其花时间猜模型为什么答错不如先把验收标准写清楚把工具描述写准确把评测环境跑干净。这才是让 Agent 真正跑稳的工程路径。如果这篇对你有帮助帮忙**点赞关注**帮助作者有动力继续更新欢迎关注公众号**蝈蝈的AI笔记**里面有更多干货内容。 原文: Tw93HiTw93发布的长推:https://x.com/HiTw93/status/2034627967926825175