Harness Engineering 详解 Harness Engineering 的定义与核心价值 Agent 可靠性的瓶颈不在模型，而在模型周围的系统。模型是引擎，Harness 是方向盘。以 LangChain Coding Agent 为例，在 Terminal Bench 排行榜中，通过仅优化 Harness（系统提示、工具配置、中间件钩子），模型未更换的情况下，排名从 30 名开外提升至前五。Harness 源自马具（缰绳、马鞍等）的比喻：模型如马（强大但无方向），人类工程师如骑手（提供方向），Har…
Multi-Agent 架构使用判断框架 Anthropic 的核心立场 大多数团队不需要 Multi-Agent 系统。在单个 Agent 上反复改进 prompt，效果可匹配花数月搭建的复杂多 Agent 架构，且代价更低。普通 Agent 消耗约 4 倍于聊天的 token，而 Multi-Agent 系统消耗约 15 倍，额外开销来自跨 Agent 的上下文复制、协调消息和结果汇总，因此需任务价值足够高才能覆盖开销。 该使用 Multi-Agent 的场景 上下文污染 不同子任务积累的信息互相干扰导致推理质…
AGENT 的核心矛盾：灵活性 vs 确定性 灵活性来源：模型自主决策，但天然带有不确定性，无法 100% 预测下一步行动。 确定性来源：人定规则，但规则写死会丧失灵活性，无法应对未覆盖情况。 关系：两者是跷跷板关系，无法同时最大化，多数 agent 项目失败源于未明确平衡点。 编程 agent 成功的关键要素 试错成本极低 代码生成结果可通过执行即时验证，错误信息可被 agent 捕获并自主修正，反馈循环为毫秒级，无需人工判断。 对比企业业务场景（如取消订单、发送邮件），试错成本极高，错误可能导致事故，无法通过多…
Agent≠调 API 的核心区别 面试中常被质疑 “Agent 只是调大模型 API”，但实际落地面临关键挑战：当对话轮次增加（如 50 轮），上下文 token 超过模型窗口（如 128K）时，需解决信息取舍问题，而非简单删除或全量发送。 上下文窗口限制与落地痛点 大语言模型上下文窗口存在硬限制（常见 128K-20 万，Gemini 达 100 万），但实际交互中： 固定开销：System Prompt + 工具说明约 4000 tokens 动态开销：每轮对话（输入 + 输出）500-2000 tokens…
多智能体场景适配和场景 多智能体运行模式 核心特点 适合的业务场景 顺序执行（Pipeline/Sequential） 流程固定、串行执行，前一步输出为后一步输入，无分支无并行 1. 内容生成（规划→写作→润色→发布）； 2. 数据处理（清洗→分析→可视化）； 3. 标准化客服流程； 4. 代码生成流水线（需求→编码→测试→修复） 监督者-工作者（Supervisor-Workers）-- 用的最多 中央监督者调度、分配任务、汇总结果，工作者专注专业任务，强管控、可审计 1. 企业级多专家系统（法律/…
