变更日志

• 本节由社区贡献者 @wikimatt 提出，经 ADPS 编辑整理。

• This section was proposed by community contributor @wikimatt and edited by ADPS.

• 近十年的人工智能进展，实践大多走在理论前面。2025 年底以来 Agent 的快速扩散尤其如此：它不是从一套理论推导出来的，而是一个个痛点被逐个解决之后累积出来的结果。补上理论这一课，第一个要回答的问题是，Agent 为什么会在“大模型加 Agent”这类方案里处在中枢位置。

• 一种能解释这段历史的说法是，分界线在于输出能不能被检验。缺少验证环节时，大模型可以一本正经地一直推理下去，没有任何机制让它停下来认错。在那个阶段，商业上跑得比较顺的多是不需要判定真伪的场景：陪伴与情绪价值不依赖外部事实确认对错，因而不受这一限制，同时也不构成生产力工具。

• 工具调用和 Agent 出现之后，模型的输出第一次可以被外部世界检验。调用有返回，动作有后果，结果可以和目标状态比对。AI 由此从提供情绪价值转向提供生产力。第一个大规模商业化的生产力场景是 AI 编程，一个重要原因是编程天然自带多层裁判：编译器、类型检查、测试用例和运行结果，都能在很短的时间内给出确定的判定。

• 由此得到一条贯穿本文的判断。一个场景能不能被 Agent 变成生产力，很大程度上取决于它的验证能不能做好；不同阶段会有不同的关键技术成为瓶颈，验证则始终是决定上限的那个变量。ADPS 反思模块第一次研讨会从另一个方向记录过相近的结论：真值什么时候到达，决定了修正应该闭合在哪一层。

• 本节由社区贡献者 @wikimatt 提出，经 ADPS 编辑整理。

• For most of the past decade, practice in artificial intelligence has run ahead of theory. The rapid spread of agents since late 2025 is a clear case: it did not follow from a body of theory, but accumulated as one concrete problem after another was solved. The first question any theory now owes an answer to is why agents sit at the centre of a "large model plus agent" system.

• One account that fits the history is that the dividing line runs through verifiability. Without a validation step, a large model can reason on indefinitely and with complete confidence, because nothing in the loop forces it to stop and concede an error. During that period the applications that worked commercially were largely those where truth did not have to be adjudicated. Companionship and emotional value do not depend on external facts to be judged correct, so they escaped the constraint, and they are also not productivity tools.

• Tool calls and agents changed this. For the first time, model output could be checked against the external world: calls return, actions have consequences, and results can be compared with a target state. That shift is what moved AI from emotional value toward productivity. The first productivity domain to commercialise at scale was AI-assisted programming, and one reason is that programming carries several layers of native adjudication. Compilers, type checks, test cases, and run results all return a definite verdict within a short interval.

• This yields a judgement that runs through the rest of this article. Whether a domain can be turned into productive work by an agent depends substantially on whether its validation can be made to work. Different stages will place the bottleneck on different technologies, but validation remains the variable that sets the ceiling. The first ADPS Reflection workshop recorded a related conclusion from another direction: when ground truth arrives determines which layer a correction should close in.

• This section was proposed by community contributor @wikimatt and edited by ADPS.

• 一位有企业软件项目经验的工程师朋友，在与黄佳的交流中提到了这些约束。七月，他在考虑用内容生产流程展示 Agent 设计，后来转向 OA 与电商，因为这些场景能接上自己做过的业务。九月，他反馈已把 Embabel 与已有业务代码结合使用，也提出了另一个限制：客户不开放原系统代码，新增能力需要从外部接入。他转来的可塑软件资料，为这类改造提供了一个比较角度。

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• 这位工程师提出把部分业务以 MCP 工具形式接出来。MCP 提供工具发现、调用及输入输出描述的协议。工具可以由适配器实现，再调用已有业务 API。客户无需先交出整个系统的源码，开发者也能围绕被允许的能力增加 Agent 工作流。MCP 工具规范

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• Embabel 值得作为另一条实现路线研究，其公开项目将领域对象、动作、目标与条件放进 JVM 和 Spring 的开发环境。已有 Java 团队可以据此考察怎样复用业务服务。这位工程师对它的采用提供了一条实践线索，但目前不足以据此判断它普遍优于其他框架。Embabel 项目

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• 实践问题来自一位工程师朋友与黄佳在 2026 年 7 月至 9 月的交流。本文保留业务约束，不公开客户资料。补发申请、数据结构及代码用于说明设计，未作为该工程师项目的实测结果。本文不预判某类开发平台会取代其他类别。

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• An engineer with experience in enterprise software raised this problem in conversations with Jia Huang. His initial interest in content-production agents shifted toward office workflows and commerce, where he had existing development experience. He later reported combining Embabel with business code and described a separate constraint: a client would not open its legacy source, so additional capabilities needed an external integration. These reports motivate the design questions below, without establishing measured production outcomes.

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• The practical questions originated in conversations between an engineer and Jia Huang from July to September 2026. Customer information is omitted. The replacement-shipment workflow, data structures, and code are explanatory designs, not measured results from the engineer's project. The article does not predict that one development category will replace the others.

  此处原文含未确认的社交昵称，按隐私规则不在公开记录中重现。

• 可塑软件：在既有业务上增加 Agent 能力 讨论源码受限时的接入方式、业务草案审批及结果核验。

• Malleable Software: Adding Agents to Existing Business Systems examines integration without source access, approval of business drafts, and verification of external results.

• 专题/Agent 模式组合

• 双轴框架帮助团队定位模式：当前问题属于哪种认知功能，采用哪种执行拓扑。真实系统还要完成下一步，把多个模式连接成一条能运行、能失败、能恢复的路径。

• 模式组合是一张有方向的关系图。节点是模式或业务步骤，边是数据、状态、授权和证据的交接。它不增加第三条坐标轴，也不要求每个方案覆盖更多模式。组合质量取决于接口是否明确，以及失败时能否判断由谁停止、回滚或接管。

• 模式/组合工具/常见模式组合

• 双轴框架是一张模式地图。企业里的应用、数据、人、政策、等待状态和验收点构成任务地形。两个团队可以选择同一组模式，因为事实和责任放置的位置不同，最后仍会形成两套架构。

• 模式组合是一张有方向的任务图。节点是业务活动或模式，边上传递任务身份、业务状态、授权和完成证据。每条重要的边都要回答谁生产、谁消费、谁可以修改，以及失败后由谁停止、补偿或接管。

另有 13 段改动未展开

• 接入 MCP 等外部工具协议：外部工具来源不可信，必须靠元数据里的来源标记加额外安全审查。

• 固定流程任务：可以更进一步走 Programmatic Tool Calling，由工程层显式编排调用序列，模型只负责填参数和解读结果，减少来回、容错更强、审计更清晰。

• 接入 MCP 等外部工具协议：工具跨越了新的信任边界，需要记录来源和版本，并按风险检查描述、参数、权限与运行行为。

• 工具密集、可用局部程序表达的任务：例如从多家门店读取库存、筛选缺货项，再为每项查询替代品。模型可以通过 Programmatic Tool Calling 生成一段受限程序，在沙箱内循环或并行调用已注册工具，先汇总结果，再把必要信息交回上下文。调用顺序来自模型生成的程序，并非工程人员预先写死；工具注册、权限、配额和每次调用的准入仍由 A1 控制。

• 运行方式如何推进任务主要边界 直接工具调用模型选择一个工具和参数，取得结果后再决定下一步每次调用都经过 A1 的候选选择和准入 ReAct推理、行动、观察交替进行；新观察直接影响下一轮判断适合路径尚不确定、需要边做边看的任务，模型往返通常较多 Programmatic Tool Calling模型先写受限程序，再由程序循环、分支、并行调用已注册工具程序负责局部控制流，工具的身份、权限和副作用边界没有改变 CodeAct模型把可执行代码作为行动语言，用代码计算、调用库或组合可用能力行动空间比已注册工具更宽，需要更严格的沙箱、资源和凭证隔离

• 这四种名称描述的层次不同。A1 负责工具注册、候选选择和调用准入；A2 可以把多阶段任务编成计划；ReAct、Programmatic Tool Calling 和 CodeAct 则说明某一步在运行时怎样推进。一次任务里生成的代码只有经过验证、命名、版本化并允许跨任务复用后，才进入 M5 程序性记忆。

另有 3 段改动未展开

• 模式/组合工具/模式选型卡

• 选型卡保存第一轮架构假设，适合在访谈或工作坊中快速对齐。进入实施前，再用六步选型法补上基线、约束、模式接缝和消融验证。系统上线后，评测回执继续记录这组模式是否真的改善了目标指标。三份材料分别回答“准备怎么做”“为什么这样做”和“做完是否有效”。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• Topics/Pattern Composition

• The dual-axis framework locates a pattern by cognitive function and execution topology. A working system needs another design step: connecting several patterns into a path that can run, fail, and recover.

• A composition is a directed relationship graph. Its nodes are patterns or business steps. Its edges carry data, state, authorization, and evidence. The matrix remains two-dimensional; composition is recorded outside it as a runtime graph. More patterns do not strengthen a design by themselves. The interfaces must be explicit, including who stops, rolls back, or takes over when a step fails.

• Patterns/Composition tools/Common Pattern Compositions

• The dual-axis framework is a map of patterns. Applications, data, people, policy, waiting states, and acceptance points make up the task terrain. Two teams can choose the same patterns and still produce different architectures because they place facts and responsibility differently.

• A composition is a directed task graph. Its nodes are business activities or patterns. Its edges carry task identity, business state, authority, and completion evidence. For every consequential edge, the design names the producer, consumer, mutation rights, and the owner of stop, compensation, or takeover.

另有 16 段改动未展开

• External tool protocols such as MCP: Record source and version, validate schemas and descriptions, and admit each server under the organization's trust policy.

  External tool protocols such as MCP: A new tool crosses a trust boundary. Record its source and version, then review descriptions, parameters, permissions, and runtime behaviour according to risk.

• Fixed procedures: Programmatic Tool Calling can move call order into the engineering layer while the model supplies bounded parameters or interprets results.

• Tool-heavy work that can be expressed as a local program: For example, read inventory from several stores, filter missing items, and query substitutes for each one. With Programmatic Tool Calling, the model writes a bounded program that loops over or parallelizes calls to registered tools inside a sandbox, reduces the results, and returns only the needed information to context. The model-generated program expresses call order; engineers do not predefine that exact sequence. A1 still governs tool registration, authority, quotas, and admission for every call.

• MechanismHow work advancesPrimary boundary Direct tool callingThe model selects one tool and its arguments, observes the result, and then chooses the next stepA1 selects and admits each call ReActReasoning, action, and observation alternate; each observation informs the next decisionUseful when the route is uncertain and work must proceed by inspection, usually with more model round trips Programmatic Tool CallingThe model writes a bounded program that loops, branches, or parallelizes calls to registered toolsThe program owns local control flow; tool identity, authority, and side-effect boundaries remain in force CodeActThe model uses executable code as its action language for computation, libraries, and available capabilitiesThe action space is broader than a registered-tool catalogue and needs stronger isolation for code, resources, and credentials

• These labels describe different layers. A1 governs tool registration, candidate selection, and call admission. A2 can schedule a multi-stage plan. ReAct, Programmatic Tool Calling, and CodeAct describe how a step proceeds at runtime. Code generated in one run becomes M5 Procedural Memory only after validation, naming, versioning, and approval for reuse across tasks.

• Plan-and-Execute (A2): A2 schedules the task graph. Each executable step may invoke A1 to select an eligible tool.

另有 1 段改动未展开

• Topics/Pattern Selection Card

  Patterns/Composition tools/Pattern Selection Card

• The card captures an initial architecture hypothesis and works well during interviews or workshops. Before implementation, use the Six-Step Selection Method to add a baseline, constraints, pattern seams, and ablation tests. After release, evaluation receipts record whether the composition actually improved the target measure. The three records answer what the team plans to build, why it chose that design, and whether the result worked.

• Composing Agent Patterns

• Six-Step Selection Method

• Common Pattern Compositions

• View in the ADPS Chronicle

• View in the ADPS Chronicle

• View in the ADPS Chronicle

• 角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师，悟空研发安全负责人 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

  角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师、架构师 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

• RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; member of the Tencent Cloud Architects Alliance Hall of Fame ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Founding Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

  RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; member of the Tencent Cloud Architects Alliance Hall of Fame ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert engineer and architect, Tencent Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Founding Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• Pattern Selection Card

• 在 ADPS Chronicle 中查看

• 在 ADPS Chronicle 中查看

• Coordinate Collaboration × Chain (pass) Cost Medium (each handoff adds one LLM call) Pattern group Collaboration patterns Summary Split a long process into N agents with clearly scoped responsibilities. After one agent finishes its leg, it passes the critical state to the next through a structured HandoffPacket (not raw text), and each agent is good at only one thing.

  Coordinate Collaboration × Chain (pass) Cost Medium (each handoff adds validation, persistence, and routing latency) Pattern group Collaboration patterns Summary Split a long process across agents with bounded responsibilities. Each agent returns a structured HandoffPacket with the state, evidence, open questions, and authority the next agent needs.

• When multi-agent systems fail, it is often not because any single agent is too weak, but because the handoff dropped the baton. A front-line agent holds all of the customer's information; when it transfers to the second tier, it passes only "the verbatim text of the customer's last sentence." The second tier picks up like a colleague who just walked in—with no idea who the customer is, why they are upset, or what has already been said—and so it asks again.

• A handoff fails when the next agent receives only the customer's last message. It lacks the customer identity, prior actions, unresolved issue, escalation reason, and permissions carried by the previous agent. The second agent then repeats questions or acts on incomplete state.

• Vertical axis · Collaboration: the output of one agent is the input of the next—relay-style multi-agent collaboration. Each leg is a peer with a clearly scoped responsibility, with no supervisor as a stable anchor—this is its biggest difference from Hierarchical Delegation.

• Horizontal axis · Chain: N agents pass strictly in sequence, neither in parallel nor in a loop. This differs from Fan-Out/Aggregate, where N workers run at the same time, and from Adversarial Review, where there is back-and-forth debate. Order sensitivity is its defining trait.

• A single handoff keeps the baton from dropping through three things:

另有 37 段改动未展开

• Coordinate Reasoning × Parallel (fan-out) Cost High (multiple branches plus aggregation) Pattern group Reasoning patterns Summary Within a single query, deliberately launch N independent reasoning chains, then use an aggregation strategy to synthesize one answer. Trade compute for accuracy.

  Coordinate Reasoning × Parallel (fan-out) Cost High (multiple branches plus aggregation) Pattern group Reasoning patterns Summary Run independent reasoning branches, preserve their evidence, and aggregate only when measured quality gains justify the added cost.

• A single reasoning chain carries a "lucky-draw bias": with the same prompt and the same model, different samples do not necessarily produce the same answer. If one chain happens to go off course, the whole conclusion is wrong, and every step looks correct along the way—the error hides in "the one feature this particular run happened to miss," which is hard to spot in a post-mortem.

• Parallel exploration replaces "bet on one chain" with "run independent chains, then merge." It does not aim to lower call cost. It spends additional compute when the cost of being wrong justifies broader evidence and independent candidates. It is complementary to complexity routing (R2): routing controls routine cost, while parallel exploration is reserved for decisions that benefit from multiple paths.

• Vertical axis · Reasoning: what runs in parallel is multiple candidate paths of the same reasoning task (several candidate solutions). This sits at the reasoning-strategy layer, rather than splitting the task across multiple agents. This is the fundamental difference from the collaboration module's "fan-out aggregation (C2)"—the latter parallelizes subtasks, the former parallelizes multiple solutions to the same problem.

• Horizontal axis · Parallel: N branches run at the same time, unaware of one another, and are aggregated in a single step at the end. This is a natural parallel structure, neither a serial chain nor an iterative loop.

• One reasoning run may omit a relevant feature or settle on a weak hypothesis. Repeating the same configuration can reproduce the same blind spot, while ordinary review sees only the selected result.

另有 31 段改动未展开

• Coordinate Collaboration × Hierarchy (split) Cost High (multiple worker calls plus coordination and synthesis) Pattern group Collaboration patterns Summary A supervisor agent dynamically splits a task, dispatches it to N worker agents for execution, and then merges the results. This is the classic multi-agent supervisor-worker collaboration.

  Coordinate Collaboration × Hierarchy (split) Cost High (multiple worker calls plus coordination and synthesis) Pattern group Collaboration patterns Summary A supervisor delegates bounded tasks and authority to workers, then verifies and integrates their artifacts against a shared contract.

• A single agent that researches, writes the body text, produces figures, and assembles the report all at once is not specialized in any of them, and across a long workflow its context keeps growing. The more subtle problem is this: when one agent processes several subtasks in sequence, the execution details of the earlier tasks stay in its context the whole time, and by the third or fourth task its reasoning quality starts to degrade.

• Hierarchical delegation replaces "one all-purpose agent" with "one supervisor plus several specialized workers." The supervisor splits the task, monitors progress, and merges the output; each worker only does the one kind of work it is good at, running in its own isolated context. This lets each segment of work be handled by an appropriate model and prompt, and it also frees the supervisor's context from execution details so it can focus on coordination. The price is that token consumption rises by a multiple, so this pattern only fits scenarios where the value of the task can cover that multiple.

• Vertical axis · Collaboration: This is genuine multi-agent role differentiation—the supervisor and the workers are different agents that carry different responsibilities, not an engineering abstraction inside a single agent. Researcher, Writer, and Visualizer each correspond to one professional capability, and this division of labor by occupational ability is the classic form of multi-agent collaboration.

• Horizontal axis · Hierarchy: The topology is a tree. The orchestrator sits on top and several workers sit below; workers do not communicate directly, and to exchange information they must go through the supervisor. This is a natural hierarchical structure, distinct from the fan-out aggregation of Parallel, the review loop of adversarial review, and the sequential handoff chain.

• A single agent may need to research, draft, generate figures, and assemble a report while carrying every intermediate trace in one context. As the workflow grows, earlier tool output and local decisions compete with the current coordination state.

另有 30 段改动未展开

• Coordinate Action × Orchestrate (coordination) Cost Medium (plan once, execute many times; heterogeneous models can cut cost substantially) Pattern group Action patterns Summary The agent first generates a complete plan (with dependency structure, resource estimates, approval nodes), then executes against the plan, doing local replanning rather than a full rewrite when it drifts.

  Coordinate Action × Orchestrate (coordination) Cost Medium (plan once, execute many times; heterogeneous models can cut cost substantially) Pattern group Action patterns Summary Represent a long task as a versioned dependency plan, execute ready steps, and replan affected future work when assumptions change.

• In a long process, a purely reactive Agent can lose the global sequence. An HR recruiting Agent may send compensation information after rejection, skip a required background check, or query the same record repeatedly when each step is chosen only from the latest observation.

  In a long process, a purely reactive agent can lose the global sequence. An HR recruiting agent may send compensation information after rejection, skip a required background check, or query the same record repeatedly when each step is chosen only from the latest observation.

• Plan-and-Execute splits the action side into two phases: plan first, then execute. The planning phase lays the task out in one pass as an ordered sequence of steps, marking dependencies, resources, and the nodes that require human review; the execution phase advances against the plan. Its value is in taking the macro-level ordering out of the model's in-the-moment judgment and pinning it into an auditable plan.

• Vertical axis · Action: the agent does not execute a single step; it turns a goal into a sequence of outward actions. The two-phase "think first, then act" belongs to the action side, not the single-point thinking of the reasoning side.

• Horizontal axis · Orchestrate: the center of Plan-and-Execute is an orchestrator—it holds the complete plan, schedules each step along the dependency graph, maintains global state and checkpoints, and does local replanning when things drift. This differs from the pure chaining of prompt chaining (A3): A3 is a linear hand-off where the previous segment's output feeds the next, whereas A2 is a central node coordinating multiple steps, where independent steps can expand in parallel, key nodes drop checkpoints, and errors can roll back and replan. This layer of coordination and recovery is exactly what distinguishes Orchestrate from Chain.

• Plan-and-Execute represents the task as a versioned plan before execution. The plan records dependencies, expected artifacts, resources, approval nodes, and acceptance conditions. A scheduler advances ready steps, writes checkpoints, and replans affected future work when assumptions change.

另有 29 段改动未展开

• Fan-out / gather splits a large task into independently executable subtasks, distributes them to parallel sub-agents, and aggregates the results at the end. It usually spends more total compute to reduce wall-clock time, although provider limits and the gather stage prevent ideal linear speedup. Dispatch is the easy part; merging the results is where most of the engineering lies. When workers see overlapping material, the aggregation stage must deduplicate and resolve conflicts.

• Vertical axis · Collaboration: This splits one task across multiple sub-agents that work in parallel and then summarize. The entities being distributed are different subtasks, which makes it a multi-agent collaboration topology. This differs from parallel exploration in the reasoning module—the latter parallelizes multiple solution paths for the same problem (a reasoning strategy), while the former parallelizes different subtasks split across different agents (a collaboration topology).

• Horizontal axis · Parallel: N sub-agents run simultaneously, unaware of one another, and are gathered together at the end. This is the classic map-reduce parallel structure. It is neither sequential chaining nor loop iteration.

• Fan-Out/Gather splits a task into independent work units, runs them concurrently, and combines typed results. It may trade higher total compute for shorter wall-clock time. Provider limits, shared dependencies, output overlap, and aggregation determine the actual speedup.

• Vertical axis · Collaboration: Fan-Out/Gather assigns independent work units to multiple participants and combines their typed results. Parallel Exploration (R3) instead runs alternative hypotheses or solution paths for the same decision.

• Horizontal axis · Parallel: Work units run concurrently without consuming one another's intermediate state. A gather owner combines their artifacts and records partial failures.

另有 29 段改动未展开

• Coordinate Reasoning × Hierarchy Cost Medium (the Talker carries most of the conversation on a cheap model; the expensive model is reserved for the Reasoner) Pattern group Reasoning patterns Summary Split the agent into a fast, shallow Talker and a slow, deep Reasoner that coordinate through a shared belief state, so the agent can think deeply while still talking to the user in real time.

• Coordinate Reasoning × Hierarchy Cost Medium (interactive and asynchronous paths can use independently evaluated models and budgets) Pattern group Reasoning patterns Summary Keep live conversation responsive while a separate Reasoner updates versioned shared state under timeout and stale-result controls.

• Vertical axis · Reasoning: It separates two reasoning modalities, real-time response and deep reasoning, into a dual-process reasoning architecture — corresponding to Kahneman's System 1 (fast, automatic, low-cost) and System 2 (slow, deliberate, high-cost). This is an engineering mapping of cognitive science onto agents, not a single reasoning channel.

• Horizontal axis · Hierarchy: The Talker is in front (fast, shallow) and the Reasoner behind (slow, deep). This is a layered division of labor, not parallel competition. The two differ in responsibility, model, and timing. The Reasoner's output influences the Talker's answer through the belief state, an upper-layer–lower-layer collaboration.

• Vertical axis · Reasoning: The pattern separates an interaction response from a slower analysis job. The two paths have different output contracts, latency budgets, and permissions.

• Horizontal axis · Hierarchy: The Talker owns the live turn; the Reasoner supplies a versioned analysis artifact through shared state. The Talker cannot present unaccepted background work as a conclusion.

另有 29 段改动未展开

• Coordinate Action × Chain (relay) Cost Medium (split into N segments, N calls, but each segment can use a cheaper model to amortize) Pattern group Action patterns Pattern summary Break a complex task into a series of small tasks. Each step runs with its own independent prompt, and the output of one step becomes the input of the next, strung together to complete the work.

  Coordinate Action × Chain (relay) Cost Medium (split into N segments, N calls, but each segment can use a cheaper model to amortize) Pattern group Action patterns Pattern summary Decompose a workflow into ordered model or tool steps with explicit input, output, and acceptance contracts. Each artifact is validated before the next step consumes it.

• Prompt Chaining breaks a large task into several independent prompts processed in sequence. Each segment does only one thing, has its own role and the model best suited to it, and has its own success criterion. The difference from a single oversized prompt is that complexity can only be brought down by splitting; stuffing it into a bigger box does not bring it down.

• Vertical axis · Action: A task one prompt cannot complete is split into several sequential prompts, each of which triggers a model call or tool output. The landing point is "doing" rather than single-point "thinking," so it belongs to the Action module.

• Horizontal axis · Chain: prompt1 → prompt2 → prompt3 is a typical linear pipeline, where the output of one segment is the input of the next. It is neither routing diversion nor graph-shaped dependency. It shares the Chain topology with Plan-Execute (A2); the difference is that A3 is a pure straight line with no replan, while A2 is a DAG with replan.

• Its engineering prototype is the Unix pipe. cat data.csv | grep ERROR | sort | uniq -c strings together several single-responsibility small programs via stdin/stdout. Each program only reads input and writes output, with no need to know who comes before or after. A prompt chain reproduces the same thing at the LLM layer, where each prompt segment is a "small program."

• Prompt Chaining separates a workflow into model or tool steps that run in sequence. Each step has a bounded responsibility, an input and output schema, a model or tool selected from step-level evaluation, and an acceptance condition. The structure makes intermediate failures visible and allows a failed step to be retried without rerunning completed work.

另有 27 段改动未展开

• Coordinate Collaboration × Hierarchy Cost Cross-cutting (a cross-cutting concern layered on top of other collaboration patterns) Pattern group Collaboration patterns Pattern summary A sub-agent runs in an isolated context and must reduce its work into a schema-formed artifact before returning. The supervisor agent consumes only the artifact, never the raw trajectory.

  Coordinate Collaboration × Hierarchy Cost Cross-cutting (a cross-cutting concern layered on top of other collaboration patterns) Pattern group Collaboration patterns Pattern summary Run each delegated worker within bounded context, tools, credentials, budget, and workspace, then return a schema-valid artifact with evidence links and failure state.

• The supervisor dispatches sub-agents, each sub-agent returns its entire working process, and the supervisor's context is quickly flooded. In a batch review, raw analyses scale with every item while the supervisor usually needs only verdicts, key findings, and evidence. It should receive the work product, not every intermediate step.

• Sub-agent isolation controls context pollution in multi-agent systems. Each sub-agent runs in an isolated context and reduces its result into a structured artifact before returning, so the supervisor consumes only the artifact. This is the boundary discipline used by hierarchical delegation and fan-out aggregation to contain context and local failures.

• Vertical axis · Collaboration: Giving a sub-agent its own context and permissions is a design that adds boundaries within collaboration. It is not simple task dispatch but adds isolation discipline to collaboration—the information flow between supervisor and sub-agent is deliberately cut down to "pass only refined conclusions."

• Horizontal axis · Hierarchy: A parent agent schedules a sub-agent, and the sub-agent runs in its own sandbox—this is a structure of hierarchy plus isolation. It shares a cell with hierarchical delegation (both sit at the Collaboration × Hierarchy intersection), but the emphasis differs—hierarchical delegation stresses dispatch, while sub-agent isolation stresses isolation plus summarized return.

• Sub-agent isolation is built from four engineering elements:

另有 27 段改动未展开

• Coordinate Reasoning × Loop (transition) Cost High (cumulative cost over many iterations; must be bounded by circuit breakers and budget caps) Pattern group Reasoning patterns Summary The agent forms a hypothesis, validates it against evidence, revises based on the result, and loops until the evidence converges or an iteration limit is reached, bringing the scientific method into reasoning.

  Coordinate Reasoning × Loop (transition) Cost High (cumulative cost over many iterations; must be bounded by circuit breakers and budget caps) Pattern group Reasoning patterns Summary Test versioned hypotheses against evidence, revise the active set, and stop on confirmation, no progress, or a hard limit.

• Iterative hypothesis testing replaces single-pass reasoning with a loop of "hypothesize → validate → revise → hypothesize again." The fundamental difference from ordinary retry is this: retry assumes that the retry itself can solve the problem, while iterative hypothesis testing assumes that each loop must update the understanding of the world. Its design center is also not "retry until success," but converging through falsification to the single hypothesis that has not been refuted. It is the dual of parallel exploration (R3): parallel opens N lines at once along the spatial dimension, while iteration runs one line many times along the time dimension.

• Vertical axis · Reasoning: It follows empirical, scientific-style reasoning of "hypothesize → validate → revise → hypothesize," not a single deduction. Each round actively revises its own belief rather than waiting for the result to stabilize.

• Horizontal axis · Loop: Multiple iterations until the evidence converges or a limit is reached form a natural loop structure. The dual-mode architecture (R5) in the same column is also in the Loop column but has a different emphasis—iteration is a single agent looping with itself to validate hypotheses, while dual-mode is two agents collaborating to split the handling of "talking" and "thinking."

• Iterative hypothesis testing maintains a set of hypotheses and updates it after each evidence-gathering step. A retry repeats an operation under the same diagnosis. This pattern changes the diagnosis, evidence request, or experiment before the next round. Parallel Exploration evaluates several branches at once; R4 revises hypotheses across time.

• Vertical axis · Reasoning: Each round proposes or updates hypotheses, requests evidence that can distinguish them, and records a verdict.

另有 24 段改动未展开

• 讨论主持 茹炳晟 核心参与者 李庆丰、张栋、罗军、唐洪山、王伟、Pylon Peng、任磊达

  主持人 茹炳晟 核心参与者 李庆丰、张栋、罗军、唐洪山、王伟、Pylon Peng、任磊达

• Discussion host Bingsheng Ru Core participants Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, Leida Ren

  Host Bingsheng Ru Core participants Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, Leida Ren

• Chair Jia Huang Core workshop guests Dong Zhang, Xianglong Huang, Qingfeng Li, Cheng Huang

  Host Jia Huang Core workshop guests Dong Zhang, Xianglong Huang, Qingfeng Li, Cheng Huang

• RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

  RoleNamePublic affiliation HostHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert HostJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• 研讨嘉宾公开身份 李庆丰新浪微博高级总监 张栋腾讯专家工程师，悟空研发安全负责人 赵翰蚂蚁 AIGC 多模态推理方向 李娣娣数智元镜产品业务负责人 钟福海去哪儿网资深技术专家 熊钰柯成都玄宿科技技术架构师、创业合伙人

• 本次研讨以 R1–R5 的公开规范为基础，检查推理在生产系统里的输入、输出、资源预算、验证和停止条件。

• 角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师，悟空研发安全负责人 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

• 这场讨论持续两小时二十七分钟。六位嘉宾带来的现场分别涉及在线问答、大型代码仓分析、多模态生成、低延迟用户服务、GIS 工具链和物理仿真。模型能力、业务知识密度、时延要求和工具成熟度各不相同，推理控制也因此落在不同位置：有时交给模型，有时写进 Harness，有时编译成确定性程序，有时必须由人补齐业务判断。

• 嘉宾没有顺着 R1–R5 逐条复述定义。讨论从“哪些请求值得深想”开始，进入树搜索、推测执行、镜像 Agent、外部验收和业务评测集，最后回到一个更实际的问题：一次推理完成以后，团队留下了什么，下次上线又凭什么相信它。

• 哪些请求值得进入深度推理，哪些可以由规则或轻量路径处理？

另有 57 段改动未展开

• ParticipantPublic role Qingfeng LiSenior Director, Sina Weibo Dong ZhangTencent expert engineer; head of Wukong R&D security Han ZhaoAIGC multimodal reasoning, Ant Didi LiBusiness Lead, Shuzhi Yuanjing Fuhai ZhongSenior Technical Expert, Qunar Yuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology

  RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• The workshop reviewed the published R1–R5 specifications and the inputs, outputs, resource budgets, verification, and stop conditions needed in a production reasoning system.

• The discussion ran for two hours and twenty-seven minutes. The six participants drew on online question answering, large codebase analysis, multimodal generation, latency-sensitive user services, GIS toolchains, and physical simulation. These settings place reasoning control in different locations. A model may hold it in one system; a harness, deterministic program, or human business process may hold it in another.

• The session did not walk through R1–R5 as a catalog. It began with deciding which requests deserve deeper reasoning, then moved through tree search, speculative execution, mirror agents, external acceptance, and business evaluation sets. The closing concern was practical: after a reasoning run, what evidence and reusable control remain, and what allows the next release to be trusted?

• Which requests need deep reasoning, and which can use rules or a lightweight path?

• How do complexity, risk, evidence gaps, and latency jointly affect routing?

另有 56 段改动未展开

• 2026 年 8 月 25 日的 ADPS 协作模块研讨会上，张海立把 LangGraph、LangChain Agent 与 Deep Agents 放在同一条技术栈里讲了一遍。这个对照解决了一个常见困惑：三者并非三套互斥的 Agent 框架，它们分别承担运行时、Agent 抽象和 Harness 的职责。

  2026 年 8 月 25 日的 ADPS 协作模块研讨会上，张海立把 LangGraph、LangChain Agent 与 Deep Agents 放在同一条技术栈里讲了一遍。海立老师告诉我们，三者并非三套互斥的 Agent 框架，它们分别承担运行时、Agent 抽象和 Harness 的职责。

• 他随后演示了更值得展开的一步。模型可以根据当前任务写出一段 JavaScript，把工具和子 Agent 当作受控函数调用；循环、分支、并行和聚合留在解释器变量中。工作流依旧受运行时约束，具体形状则在任务到来后生成。

  随后，他演示了动态子 Agent。模型可以根据当前任务写出一段 JavaScript，把工具和子 Agent 当作受控函数调用；循环、分支、并行和聚合留在解释器变量中。工作流依旧受运行时约束，具体形状则在任务到来后生成。

• Deep Agents 公开架构文档把三层关系写得很清楚。

  Deep Agents 公开架构文档梳理了三层关系的差异。

• 图 1 · 三层解决不同问题。动态子 Agent 位于 Harness 与运行时之间，不另造一套执行引擎。

• 图 1 · LangGraph 承担运行时，LangChain Agent 组装 Agent 循环，Deep Agents 提供 Harness。动态子 Agent 位于 Harness 与运行时之间。

• 这段代码不是应用预先提交的固定工作流，而是模型根据当前任务生成的临时编排。解释器负责执行它；task() 把已经配置好的子 Agent 暴露成能力；LangGraph 继续保存运行状态和事件。

  应用没有预先提交这张固定工作流图。模型根据当前任务生成临时编排，解释器负责执行；task() 把已经配置好的子 Agent 暴露成能力；LangGraph 继续保存运行状态和事件。

另有 25 段改动未展开

• At the ADPS Collaboration workshop on 25 August 2026, Haili Zhang placed LangGraph, LangChain agents, and Deep Agents on one technical stack. This resolves a recurring source of confusion: the three names do not describe mutually exclusive agent frameworks. They own the runtime, the agent abstraction, and the harness respectively.

  At the ADPS Collaboration workshop on 25 August 2026, Haili Zhang placed LangGraph, LangChain agents, and Deep Agents on one technical stack. He showed that the three names do not describe mutually exclusive agent frameworks. They own the runtime, the agent abstraction, and the harness respectively.

• His demonstration then moved one step further. A model can write JavaScript for the current task and call tools and subagents as constrained functions. Loops, branches, parallel batches, and aggregation remain in interpreter variables. The runtime still enforces the execution boundary, while the shape of this particular workflow is determined after the task arrives.

  He then demonstrated dynamic subagents. A model can write JavaScript for the current task and call tools and subagents as constrained functions. Loops, branches, parallel batches, and aggregation remain in interpreter variables. The runtime still enforces the execution boundary, while the shape of this particular workflow is determined after the task arrives.

• The public Deep Agents architecture document defines the stack directly.

  The public Deep Agents architecture document distinguishes the three layers.

• Figure 1 · The layers own different concerns. Dynamic subagents sit between the harness and runtime rather than introducing another execution engine.

• Figure 1 · LangGraph supplies the runtime, LangChain agents assemble the agent loop, and Deep Agents provides the harness. Dynamic subagents sit between the harness and runtime.

• The application did not commit this exact graph in advance. The model generated temporary orchestration for the current input. The interpreter executes it, task() exposes configured subagents as capabilities, and LangGraph continues to hold run state and events.

  The application does not define this exact workflow graph in advance. The model generates temporary orchestration for the current input. The interpreter executes it, task() exposes configured subagents as capabilities, and LangGraph continues to hold run state and events.

另有 23 段改动未展开

• 姜宁分享的 Guardrail 演进以五个公开 PR 为证据，展示装配过滤、运行时授权、身份、策略和审计怎样进入同一条工具执行路径。

• 在 ADPS Chronicle 中查看

• 姜宁分享的 Guardrail 演进以五个公开 PR 为证据，展示装配过滤、运行时授权、身份、策略和审计怎样进入同一条工具执行路径。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 在 ADPS Chronicle 中查看

• 姜宁分享的 Guardrail 演进以五个公开 PR 为证据，展示装配过滤、运行时授权、身份、策略和审计怎样进入同一条工具执行路径。

• 在 ADPS Chronicle 中查看

• 事件风暴 / 无限回环：A 发事件触发 B，B 反应又发事件触发 A，循环不收敛。必须做幂等、加事件 TTL、做回环检测。

  事件风暴或回环：A 触发 B，B 再触发 A。消费者需要幂等键、事件 TTL、重复检测、配额和熔断。

• 编排（Orchestration）模式有一个中央指挥，挨个命令每个 agent "你做这步、再做那步"。这套结构在大多数场景下是对的，但它有两个会顶到天花板的硬约束：中央指挥本身是单点，它挂了整条流程就停；每加一个新 agent，都要回去改中央指挥的逻辑。当 agent 的数量和种类不断增长、业务边界又分属不同团队时，这个中央点会从协调者变成瓶颈。

• 编舞用于降低多 Agent 之间的直接耦合。每个 Agent 只订阅相关事件，处理后将结果发布到共享事件流。全局行为由各 Agent 的“订阅—处理—发布”规则共同形成。新增 Agent 时，只需配置其订阅和发布事件。

• 编舞与编排的主要差异在控制权位置：编排由中央节点持有 plan，编舞将控制分散到事件订阅者。

• 编舞当前作为扩展拓扑登记，不占用核心六列。

• 纵轴 · 协作：编舞描述的是多个 agent 怎么协同，没有单个 agent 的版本，所以纵轴稳稳落在协作模块。

另有 38 段改动未展开

• C6 编舞采用另一条判据。多个参与者订阅事件，依据本地规则行动并发布新事件，没有单一节点掌握完整计划。动态工作流和编舞都能在运行时变化，区别在于控制权放在哪里。会后保留 C6 的候选地位，并明确动态子 Agent 不能直接作为编舞案例。

• 编舞可以用一条订单链看清楚。支付服务发布 PaymentConfirmed；库存服务订阅后预留库存，再发布 StockReserved；物流和通知服务各自订阅这个新事件并行动。每个参与者只掌握本地规则，没有一个 Orchestrator 保存“付款—库存—物流—通知”的完整计划。相反，模型即使在运行时临时选择子 Agent，只要仍由一个解释器保存计划、决定调用顺序并汇总结果，它就是动态编排。流程会不会变化不是判据，完整计划由谁持有才是判据。C6 因此继续保持候选地位。

• 动态编排仍由一个节点持有完整计划；编舞由参与者根据事件和本地规则推进。

• 张栋提出，许多 runtime graph 最终都能拆成串行、并行和路由。这项判断解决的是框架实现，不是设计语义。一个“负责人分派—Worker 执行—负责人验收”的层级任务，和一个“生成者—评审者—裁决者”的对抗任务，可以使用相似的边，却不能交换责任和权限。

• 张栋随后把拓扑与身份、权限、防护和溯源交叉检查。例如负责人有权读取整批数据，不代表核验单条记录的 Worker 应继承同样范围；聚合节点需要读所有分支结果，也不因此获得修改源记录的权力。

• 王伟把遗漏的第三类关系补了出来。Agent 之间可以完整交接，人与 Agent 也可以完成审批，但产品、研发和测试在会议中形成的决定若不进入版本化资产，下一轮 Agent 仍然不知道哪些路径已经被否决。

另有 4 段改动未展开

• 每个 Hook 声明事件、顺序、读取与写入、幂等键、失败语义、后续事件、所有者和版本。运行时展示最终组合，避免控制流藏在注册顺序与回调代码中。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 治理与协作模块研讨会；G5 钩子流水线。

• 团队在“需求完成后”触发编码 Agent，在高危工具调用前暂停审批，在调用后记录 trace，并在失败时保存 checkpoint。实现上都可以叫 Hook，设计责任却分别属于流程编排、治理、观测和恢复。若回调散落在配置和插件中，真实控制流很难从主图中看见。

• Hook 组合把多个确定性触发点当作一条有顺序、有状态的控制链来设计。每个 Hook 声明触发事件、执行条件、读写对象、优先级、幂等键、失败语义和后续事件；组合层负责冲突检测和执行顺序。

• 职责示例失败时编排规格确认后启动编码不应重复创建同一任务治理写入生产前等待审批阻断调用并保留恢复点观测记录请求、裁决和回执按风险决定阻断或降级恢复保存 checkpoint、释放租约必须可重试且保持幂等

另有 2 段改动未展开

• 抽象压缩角色与机制，还原恢复对象、状态、权限、证据、异常和验收。会改变业务判断、状态迁移、权力边界、证据效力、后续动作、责任或验收的差异必须保留。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 协作模块第一次研讨会；ADPS 模式审校方法。

• 批量筛选简历和批量检查代码都可以抽象成“扇出—处理—聚合”。回到现场以后，简历任务可能需要隐藏敏感字段并由招聘负责人裁决，代码任务则需要隔离 worktree、运行测试并由仓库所有者合并。如果只保留箭头相同，就无法指导权限、状态和验收设计。

• 抽象—还原往返包含两个方向。抽象从多个案例提取可复用的问题、约束和结构；还原把结构放回具体角色、对象、状态、权限、证据、失败后果和验收条件，检查它是否仍能工作。还原失败说明抽象过度，或模式尚未写清适用边界。

• 每个候选模式至少经过两次还原：一次回到最初案例，确认没有删除决定成败的差异；一次进入独立领域，确认它不依赖原案例的专有名词。凡会改变业务判断、状态迁移、权力边界、证据效力、后续动作、责任归属或验收结果的差异，都需要保留或写入适用条件。

另有 1 段改动未展开

• 合同定义必需字段、可信来源、冲突处理、时间范围、敏感信息规则、token 预算和缺失时的回退。它把上下文组装从临时 Prompt 技巧变成可测试接口。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 感知模块第一次研讨会；P1/P2。

• 一个 Coding Agent 收到了几十个源码文件，却不知道这次修改为什么发生、哪些接口不能动、成功需要通过哪些检查。另一个 Agent 只收到一句“修复登录问题”，连错误日志和复现步骤都没有。两者的问题分别是信息过量和关键证据缺失。

• 上下文合同规定某类任务开始前必须具备的信息、允许加载的信息、来源优先级和验收材料。常用结构包括 Why（目标与业务原因）、What（对象、范围与非目标）、How（约束、接口和可用能力）以及 Acceptance（测试、回执或人工裁决）。

• P1 信息在任务开始前必须具备，例如目标对象、权限范围和不可破坏的接口；缺失时进入澄清。P2 信息按步骤加载，例如相邻实现、历史决策和领域材料；它们可以通过检索补充，但必须保留来源、版本和适用范围。合同本身进入版本管理，任务 trace 记录实际加载了哪些条目。

另有 1 段改动未展开

• Intent 保存主体、工具版本、规范化参数、资源范围、影响和业务前置条件。Approval 绑定其摘要、审批人、有效期和次数；恢复时重新读取外部状态，前置条件变化则重新审批或终止。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 治理模块第一次研讨会；G1 审批门。

• 审批人同意“把员工 E-1842 的交通津贴从 800 调到 1000，下月生效”。Agent 暂停数小时后恢复，期间员工状态、当前金额、政策版本或工具版本发生变化。若系统只保存一个“已批准”布尔值，执行器无法证明现在提交的仍是原动作。

• 持久化意图是在等待、重试和恢复期间保持稳定的规范化动作记录。它冻结主体、目标资源、期望变化、工具与参数版本、风险、前置条件和恢复策略。审批针对该意图的摘要签发，而不是笼统批准一段会继续变化的对话。

• 系统分别保存 Intent、Approval 和 Execution。Approval 绑定意图哈希、审批人、有效期和消费次数；恢复时重新读取可变状态，检查员工是否仍在职、当前值是否仍为 800、政策是否仍适用。前置条件不成立时，旧批准失效并重新审批或终止。

另有 1 段改动未展开

• 合同包含当前目标、带版本产物、已定决定、否决路径、未决问题、权限范围、验收检查和下一项交付。接收方显式接受或拒绝，上一段临时权限按策略回收。

  交接合同是协作节点之间的类型化边界。它传递目标、已有产物、已确认决定、未决问题、权限范围、责任主体、验收条件和下一项必需产物。接收方显式接受或拒绝，发送方的临时权限按策略回收。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• C4 交接链；协作模块第一次研讨会。

• 需求 Agent 完成分析后，把数万字对话全部交给实现 Agent。接收方知道讨论过什么，却不知道哪项决定已经确认、哪些方案被否决、自己可以修改哪些资源，以及交付结果由谁验收。上下文很多，责任仍然模糊。

• goal: 保持公共接口兼容并完成服务端修改 artifacts: [spec://417@sha256:...] decisions: - 不修改公共 schema authority: tools: [repo_read, patch_write] scope: repo://service-a acceptance: [unit_tests, contract_tests] next_required: 可评审补丁与测试证据

• 合同引用大文件和历史记录，不复制全部内容。若依赖版本、目标范围或权限发生变化，接收方应拒绝旧合同或请求重新签发，而不是静默猜测。

另有 1 段改动未展开

• 编译器检查步骤依赖、输入输出类型、工具准入、资源范围、幂等、补偿和验收，形成可调度的 PlanStep 或 DAG。自然语言计划保留为说明，不直接取得执行权。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 行动模块第一次研讨会；A2 规划执行。

• Agent 生成了一份“读取员工资料、计算调整、批量提交、发送通知”的计划。文字顺序通顺，却没有说明提交前必须取得审批，两个步骤同时写同一张表，通知还可能在事务失败前发出。等到 Executor 逐步执行，问题已经进入真实系统。

• Plan 编译把模型生成的结构化计划转换为可执行图，并在执行前完成合法性、依赖、权限、冲突、经济性和验收检查。无法通过的计划返回明确诊断，供模型修订或交给人工，而不是边执行边猜。

• 编译器验证步骤类型和参数 schema，补全显式依赖，计算写入冲突域，检查调用者权限与工具版本，并估算重复扫描、串并行选择、调用次数和预算。编译产物固定计划哈希、节点合同、资源键和恢复策略；运行时只能在声明的动态位置内调整。

另有 1 段改动未展开

• 模型负责模糊意图理解、规划和候选生成；规则、状态机、身份、权限、测试、幂等和外部回执处理必须可复现的边界。外壳约束风险，不要求把所有流程写死。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 用户用自然语言描述一笔复杂付款，模型适合提取目标、识别缺失信息并提出候选步骤。到了收款人身份、金额精度、账户状态、授权额度和幂等提交，这些条件必须得到同样输入时给出同样结果，并留下可复核证据。

• 概率内核承担开放理解、规划和候选生成；确定性外壳承担身份、状态、权限、约束、测试、提交和外部回执。内核可以提出动作，外壳决定动作能否获得执行资格，并验证现实世界是否真的改变。

• 自然语言目标 → 模型生成结构化 Intent → schema / policy / state / authority 校验 → 受控工具调用 → 回执与写后读取 → 结果进入 trace 与后续评测

• 外壳并不要求把全部流程写死。模型仍可以动态选择候选工具和步骤，但只能从带版本的能力中选择，提交前后必须通过可重复的检查。

另有 1 段改动未展开

• 拓扑只说明控制怎样展开。生产评审还要检查每一跳代表谁、权限如何收窄、错误在哪里停止，以及全链路怎样追溯。矩阵把协作模式与 X1 可观测性、X3 安全与身份连接起来。

• 这个概念用于定位可观察的工程结构。落到项目时仍要写出数据结构、控制位置、版本、责任者和验证方法；仅有名称或类比不足以证明设计已经成立。

• 一个负责人把 800 份简历分给多个 Worker 并行核验。运行图说明了怎样分片和汇总，却没有说明 Worker 以谁的身份工作、能读取哪些字段、是否可以写回，以及汇总者如何追溯每条结论。若所有 Worker 直接继承负责人的长期 Token，并行会把最大权限同时复制到全部分支。

• 拓扑治理矩阵把串行、并行和路由等运行结构，与身份、权限、防护和溯源四个控制维度交叉检查。前者说明控制如何展开，后者判断这种展开是否具备生产条件。

• 结构需要额外回答的问题串行每一跳代表谁，交接后哪些临时权限必须回收，错误怎样阻止继续下传并行分片是否隔离，聚合者是否默认只读，子链路怎样归入同一 trace路由路由依据是否留证，高风险分支是否收紧权限，未知类型怎样兜底

• 有效权限通常取用户授权、任务范围、Agent 职责、工具能力和资源边界的交集。矩阵应在设计评审、部署检查和事故复盘中使用同一组字段。

另有 1 段改动未展开