一些概念

1. Agent 开发 （Agent Development）是指: 作为开发者, 使用 Lang-chain / graph 等 SDK 来编排工程——设计状态机、写节点逻辑、实现上下文策略、处理错误恢复。核心价值在编排架构和工程可靠性。
2. Harness = Agent 系统里除了模型推理(LLM-api)之外的所有东西。模型是"大脑"，Harness 是"身体+神经系统"——负责感知环境（组装上下文）、执行动作（调用工具）、记住事情（状态管理）、避免危险（权限控制).
   因此, agent 开发 与 harness 是几乎重叠的对应关系.
3. Agent 应用（Agent Application） = ClaudeCode + MCP/Skill. 此时 你是用户，CC 是平台。你在做集成配置——写 Skill 注入领域知识、开发 MCP 扩展工具能力、定义 Custom Agent 角色。核心价值在领域 Know-how 和 Prompt 工程，不在编排基础设施。
4. 低代码 Agent 编排: 介于 Agent 应用和 Agent 研发之间的中间层. 如在 阿里云百炼上 低代码 拖拽工作流, 这确实在做编排——定义节点、连线、条件分支、循环，这些本质上就是在设计工作流图，跟 LangGraph 用代码定义图是同一件事。但你不需要写 Harness 代码，平台帮你把执行引擎、上下文传递、错误重试这些都封装好了，你只负责"画图"。

1. agent 编排

编排英文为 orchestration [ˌɔːkɪˈstreɪʃn].
大模型应用场景下是指, 有一个主 Agent（orchestrator）负责理解用户意图、拆解任务、分发给合适的执行者，并汇总结果.
实现层面通常有以下几种模式.

1. 顺序链（Sequential Chain）: 最简单，A 的输出作为 B 的输入，依次串联。
2. 并行分发汇总（Fan-out / Fan-in）: 主 Agent 把任务拆成几个独立的子任务，同时派发给多个子 Agent 并行执行，等全部完成后汇总。比如"分别调研三个竞品，然后写对比分析"。
3. 路由（Routing）——主 Agent 根据输入内容判断应该走哪条路径或交给哪个专家 Agent。比如一个客服系统，根据用户问题类型路由到"退款"“物流”"技术支持"等不同处理分支。
4. 分层委托（Hierarchical Delegation）——多层结构，顶层 Agent 做战略规划，中层 Agent 做战术分解，底层 Agent 执行具体操作。适合复杂的多步骤任务。

做个表格对比.

补充介绍一下 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 处理灵活子任务。