一些概念Agent 开发Agent Development是指: 作为开发者, 使用 Lang-chain / graph 等 SDK 来编排工程——设计状态机、写节点逻辑、实现上下文策略、处理错误恢复。核心价值在编排架构和工程可靠性。Harness Agent 系统里除了模型推理(LLM-api)之外的所有东西。模型是大脑Harness 是身体神经系统——负责感知环境组装上下文、执行动作调用工具、记住事情状态管理、避免危险权限控制).因此, agent 开发 与 harness 是几乎重叠的对应关系.Agent 应用Agent Application ClaudeCode MCP/Skill. 此时 你是用户CC 是平台。你在做集成配置——写 Skill 注入领域知识、开发 MCP 扩展工具能力、定义 Custom Agent 角色。核心价值在领域 Know-how 和 Prompt 工程不在编排基础设施。低代码 Agent 编排: 介于 Agent 应用和 Agent 研发之间的中间层. 如在 阿里云百炼上 低代码 拖拽工作流, 这确实在做编排——定义节点、连线、条件分支、循环这些本质上就是在设计工作流图跟 LangGraph 用代码定义图是同一件事。但你不需要写 Harness 代码平台帮你把执行引擎、上下文传递、错误重试这些都封装好了你只负责画图。1. agent 编排编排英文为 orchestration[ˌɔːkɪˈstreɪʃn].大模型应用场景下是指, 有一个主 Agentorchestrator负责理解用户意图、拆解任务、分发给合适的执行者并汇总结果.实现层面通常有以下几种模式.顺序链Sequential Chain: 最简单A 的输出作为 B 的输入依次串联。并行分发汇总Fan-out / Fan-in: 主 Agent 把任务拆成几个独立的子任务同时派发给多个子 Agent 并行执行等全部完成后汇总。比如分别调研三个竞品然后写对比分析。路由Routing——主 Agent 根据输入内容判断应该走哪条路径或交给哪个专家 Agent。比如一个客服系统根据用户问题类型路由到退款“物流”技术支持等不同处理分支。分层委托Hierarchical Delegation——多层结构顶层 Agent 做战略规划中层 Agent 做战术分解底层 Agent 执行具体操作。适合复杂的多步骤任务。做个表格对比.维度顺序链扇出/扇入路由分层委托执行速度最慢串行快并行快单次转发中等层间有等待上下文管理长链易丢失fan-in 处集中压力简单单轮分层隔离各层负担小适用复杂度低3-4步以内中可并行的独立子任务低分类问题高多维度、多层次调试难度低中低高这个场景的适合度勉强能用很适合不太匹配适合但有点 over-engineering补充介绍一下 fan-in, fan-out 的有趣命名, 它借用了数字电路领域的概念.Fan-out 原意是扇出在数字电路里指的是一个逻辑门的输出能驱动多少个下游门的输入。想象一个信号从一个点散出去像扇子一样展开——一个变多个这就是 fan-out。Fan-in 反过来是多个输入汇聚到一个点。扇子的多条辐条收回到扇柄。2. 桌面 agent 的编排如 claude code, 阿里 qoderWork, 腾讯 workbuddy. 这类桌面智能体的编排思路和 LangGraph 那套其实有本质区别。它们不是在用某个编排框架而是LLM 本身就是编排器。没有预定义的图、没有写死的流程每一步该做什么完全由模型在运行时决定。学术上叫 Agentic Loop工程上更直白的叫法是 LLM-as-Orchestrator。子 Agent 是按需创建并启动的,上下文管理是最关键的编排。 模型的上下文窗口是有限的什么时候该塞什么信息进去这就是编排。2.1 claude code 的编排Claude Code 不开源, 不过它的 TypeScript 源码曾发生过泄露, 社区做了很多逆向分析现在我们大致能看清楚它的编排是怎么设计的.核心编排一个 9 步流水线的 ReAct 循环CC 的编排不是 LangGraph 那样的图引擎而是一个 AsyncGenerator 实现的 while 循环每一轮 turn 走 9 步设置解析 → 状态初始化 → 上下文组装 → 5 层压缩 → 模型调用 → 工具分发 → 权限门 → 工具执行 → 停止条件每次调模型之前会先跑 5 层压缩管道从便宜到贵的渐进式降级Budget Reduction → Snip → Microcompact → Context Collapse → Auto-Compact。这 5 层压缩本身就是一个精密的编排策略——只有在前面几层不够用时才会触发更贵的操作永远用最小代价维持上下文质量。工具执行有两条路径StreamingToolExecutor模型还在流式输出时就开始执行工具追求低延迟和 runTools等模型完全输出后再分类执行区分并发安全和互斥的工具。同一个模型接不同的执行策略响应速度就能差一截。上下文和记忆完全文件化不用向量库CC 不用向量数据库做记忆检索。它是文件化的4 层 CLAUDE.md 层级managed → user → project → local检索时让一个轻量 LLM 扫描文件头选出最多 5 个相关文件加载。不是嵌入向量、不是语义搜索就是最简单粗暴但完全可审计的方案。这个选择和大部分 RAG 系统背道而驰但它有一个很硬的理由文件化意味着开发者可以直接用 git 管理记忆、用编辑器修改、完全透明。2.2 查看 claude code 的请求明文Q可以通过 http 请求拦截, 看到 每次 cc 向 云端大模型发送了啥么?A 既然 CC 支持配置自定义 provider, 我们可以在中间架一层自己的透传代理不需要劫持证书、不需要解密直接在服务端拿到明文。做法很简单起一个 HTTP 服务对外暴露 OpenAI-compatible 的 /v1/chat/completions 接口收到请求后原封不动记日志再转发给真正的 Anthropic API把响应也记下来再透传回去。CC 那边配成指向你自己的地址就完事了。市面上已经有现成的轮子比如 LiteLLM 就是干这个的.3. Agent 编排的发展趋势当前趋势是编排从显式变隐式——从开发者写流程图变成模型自己决定流程。但这不代表传统编排会消亡生产环境最终需要的可能是一个混合方案外层用确定性的编排框架保证可靠性和可观测性内层的每个节点用 Agentic LLM 处理灵活子任务。 agent 开发与 harness
一些概念Agent 开发Agent Development是指: 作为开发者, 使用 Lang-chain / graph 等 SDK 来编排工程——设计状态机、写节点逻辑、实现上下文策略、处理错误恢复。核心价值在编排架构和工程可靠性。Harness Agent 系统里除了模型推理(LLM-api)之外的所有东西。模型是大脑Harness 是身体神经系统——负责感知环境组装上下文、执行动作调用工具、记住事情状态管理、避免危险权限控制).因此, agent 开发 与 harness 是几乎重叠的对应关系.Agent 应用Agent Application ClaudeCode MCP/Skill. 此时 你是用户CC 是平台。你在做集成配置——写 Skill 注入领域知识、开发 MCP 扩展工具能力、定义 Custom Agent 角色。核心价值在领域 Know-how 和 Prompt 工程不在编排基础设施。低代码 Agent 编排: 介于 Agent 应用和 Agent 研发之间的中间层. 如在 阿里云百炼上 低代码 拖拽工作流, 这确实在做编排——定义节点、连线、条件分支、循环这些本质上就是在设计工作流图跟 LangGraph 用代码定义图是同一件事。但你不需要写 Harness 代码平台帮你把执行引擎、上下文传递、错误重试这些都封装好了你只负责画图。1. agent 编排编排英文为 orchestration[ˌɔːkɪˈstreɪʃn].大模型应用场景下是指, 有一个主 Agentorchestrator负责理解用户意图、拆解任务、分发给合适的执行者并汇总结果.实现层面通常有以下几种模式.顺序链Sequential Chain: 最简单A 的输出作为 B 的输入依次串联。并行分发汇总Fan-out / Fan-in: 主 Agent 把任务拆成几个独立的子任务同时派发给多个子 Agent 并行执行等全部完成后汇总。比如分别调研三个竞品然后写对比分析。路由Routing——主 Agent 根据输入内容判断应该走哪条路径或交给哪个专家 Agent。比如一个客服系统根据用户问题类型路由到退款“物流”技术支持等不同处理分支。分层委托Hierarchical Delegation——多层结构顶层 Agent 做战略规划中层 Agent 做战术分解底层 Agent 执行具体操作。适合复杂的多步骤任务。做个表格对比.维度顺序链扇出/扇入路由分层委托执行速度最慢串行快并行快单次转发中等层间有等待上下文管理长链易丢失fan-in 处集中压力简单单轮分层隔离各层负担小适用复杂度低3-4步以内中可并行的独立子任务低分类问题高多维度、多层次调试难度低中低高这个场景的适合度勉强能用很适合不太匹配适合但有点 over-engineering补充介绍一下 fan-in, fan-out 的有趣命名, 它借用了数字电路领域的概念.Fan-out 原意是扇出在数字电路里指的是一个逻辑门的输出能驱动多少个下游门的输入。想象一个信号从一个点散出去像扇子一样展开——一个变多个这就是 fan-out。Fan-in 反过来是多个输入汇聚到一个点。扇子的多条辐条收回到扇柄。2. 桌面 agent 的编排如 claude code, 阿里 qoderWork, 腾讯 workbuddy. 这类桌面智能体的编排思路和 LangGraph 那套其实有本质区别。它们不是在用某个编排框架而是LLM 本身就是编排器。没有预定义的图、没有写死的流程每一步该做什么完全由模型在运行时决定。学术上叫 Agentic Loop工程上更直白的叫法是 LLM-as-Orchestrator。子 Agent 是按需创建并启动的,上下文管理是最关键的编排。 模型的上下文窗口是有限的什么时候该塞什么信息进去这就是编排。2.1 claude code 的编排Claude Code 不开源, 不过它的 TypeScript 源码曾发生过泄露, 社区做了很多逆向分析现在我们大致能看清楚它的编排是怎么设计的.核心编排一个 9 步流水线的 ReAct 循环CC 的编排不是 LangGraph 那样的图引擎而是一个 AsyncGenerator 实现的 while 循环每一轮 turn 走 9 步设置解析 → 状态初始化 → 上下文组装 → 5 层压缩 → 模型调用 → 工具分发 → 权限门 → 工具执行 → 停止条件每次调模型之前会先跑 5 层压缩管道从便宜到贵的渐进式降级Budget Reduction → Snip → Microcompact → Context Collapse → Auto-Compact。这 5 层压缩本身就是一个精密的编排策略——只有在前面几层不够用时才会触发更贵的操作永远用最小代价维持上下文质量。工具执行有两条路径StreamingToolExecutor模型还在流式输出时就开始执行工具追求低延迟和 runTools等模型完全输出后再分类执行区分并发安全和互斥的工具。同一个模型接不同的执行策略响应速度就能差一截。上下文和记忆完全文件化不用向量库CC 不用向量数据库做记忆检索。它是文件化的4 层 CLAUDE.md 层级managed → user → project → local检索时让一个轻量 LLM 扫描文件头选出最多 5 个相关文件加载。不是嵌入向量、不是语义搜索就是最简单粗暴但完全可审计的方案。这个选择和大部分 RAG 系统背道而驰但它有一个很硬的理由文件化意味着开发者可以直接用 git 管理记忆、用编辑器修改、完全透明。2.2 查看 claude code 的请求明文Q可以通过 http 请求拦截, 看到 每次 cc 向 云端大模型发送了啥么?A 既然 CC 支持配置自定义 provider, 我们可以在中间架一层自己的透传代理不需要劫持证书、不需要解密直接在服务端拿到明文。做法很简单起一个 HTTP 服务对外暴露 OpenAI-compatible 的 /v1/chat/completions 接口收到请求后原封不动记日志再转发给真正的 Anthropic API把响应也记下来再透传回去。CC 那边配成指向你自己的地址就完事了。市面上已经有现成的轮子比如 LiteLLM 就是干这个的.3. Agent 编排的发展趋势当前趋势是编排从显式变隐式——从开发者写流程图变成模型自己决定流程。但这不代表传统编排会消亡生产环境最终需要的可能是一个混合方案外层用确定性的编排框架保证可靠性和可观测性内层的每个节点用 Agentic LLM 处理灵活子任务。