第一步：任务分析这个任务有哪些不同性质的子任务？（搜索？实现？审查？测试？哪些子任务可以并行？哪些有依赖必须串行？有没有需要"第二视角"来对抗验证的环节？第二步：角色设计每个 Agent 有且只有一个明确的职责执行者 ≠ 审查者 ≠ 验证者（三个不同 Agent 实例）每个角色的 System Prompt 有明确的"该做什么"和"不能做什么"Manager 不亲自执行具体工作第三步：协作模式选择

ReAct（Reasoning + Acting）是 2022 年由 Google 和普林斯顿提出的框架，核心思想是让语言模型交替进行推理和行动，而不是一次性生成最终答案。- 用户提问 → 模型思考 → 生成最终答案- 问题：模型在"真空"中思考，无法获取外部信息- 用户提问 → Thought(思考) → Action(行动) → Observation(观察) → Thought → Acti

这是面试里最能区分理解深度的地方。A2A 明确把 task state 提上来了，因为 Agent 任务天然是长生命周期的。

保持简洁：在设计中维持简单性，不要为了"智能"而增加不必要的复杂性优先透明：明确显示智能体的规划步骤，让用户和开发者都能理解决策过程精心设计接口：通过彻底的工具文档和测试来优化 ACI。

为改进 token 选择而部署的代码意外触发了 XLA:TPU 编译器中的一个潜在漏洞。用户报告模型"变笨了"、"输出出现奇怪的字符"、"回答质量不稳定"。如果你的 Agent 部署在多个平台，需要分平台监控。Anthropic 不仅公开承认了问题，还详细解释了每个漏洞的技术细节——包括 XLA 编译器的底层 bug。这些都不是显而易见的故障，需要细致的监控和分析。Anthropic 发布了这篇坦

你修复了一个 Bug，不知道有没有引入新的；你优化了一个提示，不确定其他场景有没有退化。这篇文章是 Anthropic 写的最全面的 Agent 评测指南，覆盖了从概念到实操的完整链条。问："Agent 能做什么？" 针对 Agent 目前还做不好的任务，设定改进目标。没有评估，你就无法衡量进步。投入到评估中的每一分钟，都会在后续迭代中产生复利效应。问："Agent 是否还能做它以前能做的？" 通

一个简洁但很有力的定义是：\Agent 状态机就是把 agent 运行过程表示为一组离散状态以及状态之间在特定条件下的转移规则。这不是说 agent 要做成非常僵硬的传统有限状态机，而是说：\即使内部某些步骤由模型自由决策，系统外层仍应有明确的阶段与转移控制。这就是局部自治，外层受控。很多 agent 死循环，不是因为工具有 bug，而是因为完成这个概念没有被定义清楚。调研哪些维度；需要多少个来源

什么是 Agent几乎是所有 Agent 面试的起手题，但它真正考察的绝不是百科式定义，而是候选人有没有建立清晰的边界意识。面试官通常借这个问题判断三件事：第一，你是否真的理解 agent 和 chatbot、workflow、tool-calling app 的区别；第二，你是否知道 agent 什么时候有必要、什么时候没有必要；第三，你是否具备将看起来很智能的概念落到可上线、可治理、可控风险的

策略原理延迟保真度成本最佳场景直接截断只保留最近 N 条消息<1ms低（旧信息全丢）零短对话、简单任务滑动窗口保留最近 K 轮 + 重叠<1ms中（有上下文连续性）零中等长度对话关键词提取TF-IDF / BM25 保留高分消息10-50ms中低（关键词匹配不准）极低明确关键词的场景LLM 摘要调用模型生成压缩摘要200ms-1s中高（语义保留）中（一次 API 调用）长对话、多轮任务语义向量检索

功能列表、进度文件、git 提交——这些不是什么新发明，而是软件工程师每天都在用的工作方法。最好的 Agent 框架设计，就是把最好的人类工程实践编码化。想象一个软件项目的工程师轮班工作，每个新工程师对上一班次发生的事情一无所知。这就是长时间运行 Agent 面临的困境。在已经构建了一些功能之后，后续的 Agent 实例四处查看，看到已有进展，就宣布工作完成了。Agent 试图一次性完成整个应用程