分类：Agent 工程

把 33 篇内容重新串成一条判断路径：先看任务，再看上下文、工具、状态、协作和质量，而不是先问该用哪个框架。

部署后要面对网络、模型限流、上下文过长、外部服务不可用和进程崩溃。可靠性来自明确的降级和恢复协议。

没有报错不代表完成任务。日志、轨迹、单元测试、集成测试和 Eval 要共同回答发生了什么、是否正确以及是否退化。

真正稳定的 Agent 依赖的不只是模型，还包括配置、工具、状态、策略、事件、恢复和运行入口组成的 Harness。

并行能缩短等待，但会增加重复、合并和限流成本。编排应该由任务依赖和证据需求决定。

多 Agent 不是简单复制线程。任务边界、上下文隔离、结果预览、通知和生命周期才是协作的难点。

模型文本、工具进度、后台通知和输入状态会同时变化，界面应该消费语义事件，而不是直接监听内部函数。

路径边界、图片临时注入、写前快照和冲突检测共同决定 Agent 改文件是否可控。

“先给计划，不要执行”、进度清单和持久化任务图是三件不同的事，应该由不同状态和模块负责。

记忆可能过时、冲突、过度泛化、被污染或无法追溯。可靠记忆需要年龄、来源、验证和删除机制。

聊天记录、会话状态、项目记忆和用户偏好生命周期不同。先分层，再决定文件还是数据库。

知识库不是文件堆。把结论、来源、关系、版本和验证状态结构化，Agent 才能持续积累而不是重复聊天。

用户问的是“我现在该改哪里”，检索却可能返回一堆“概念相似”的旧文章。任务、权限、时间和证据都要进入排序。

RAG 不只是向量检索。切分、元数据、召回、重排、引用和过期处理共同决定知识能不能被可靠使用。

启动时把所有文件、工具和记忆都塞给模型，会让上下文拥挤且陈旧。按需读取更接近真实工作。

Prompt Cache、KV Cache、Context Collapse 不是一回事。理解缓存边界，才能解释延迟和成本为什么突然上升。

对话、工具输出和子任务结果都会增长。压缩保留语义，预算控制注入，Offload 保存完整正文，三者不能混为一谈。

把 Prompt 变成带稳定性和类别元数据的管道，避免每轮变化的 Git 状态、日期和任务列表污染稳定前缀。

上下文同时涉及选择、顺序、预算、时机和新鲜度。只会写 system prompt，还远远不够。

权限不是工具名称上的一个 readonly 标记，而是路径、参数、环境、审批和审计共同组成的纵深防线。

MCP 让远程能力有了统一插槽，但连接、超时、版本、权限和数据边界仍然要由宿主应用负责。

工具描述也占上下文。工具数量变多后，按需加载、搜索和动态注册比把全部工具常驻更可靠。

把一次读文件或跑命令拆成可检查的流水线，才能知道问题出在参数、路径、进程、输出还是模型理解。

工具一多，超时、权限、Hook、审计和结果裁剪不能靠每个函数各写一套。注册表是副作用的统一边界。

工具调用不是模型直接执行代码，而是模型按照 schema 表达一个结构化意图，再由应用决定是否执行。

模型返回的可能是文字、思考、工具调用、用量和警告。正确拆分这些 part，才能同时做好 UI、审计和下一轮请求。

当 Loop 加入中断、重试、并发和后台任务后，单个布尔值 done 已经不够。显式状态能让行为可测试。

模型看一眼、决定下一步、系统执行，再把结果交回模型。真正的难点在消息演进和停止条件。

框架可以节省样板代码，却不能替你决定权限、状态、失败恢复和观测边界。先理解原理，再决定抽象层。

不需要先读完论文，但要理解 token、上下文窗口、reasoning、tool call 和 provider 差异，否则很多工程问题会被误判成 Prompt 问题。

Claude Code、Cursor、Manus 看起来差异很大，但都在处理同一组问题：循环、工具、上下文、记忆、协作和 Harness。

用户只想看帮助时，不应该先加载模型、MCP 和终端 UI。启动边界决定了速度、可测试性和故障半径。

先不急着选框架，沿着一次读取文件的请求，认识入口、上下文、Loop、工具、状态、界面和观测七层边界。