agentic-harness-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agentic Harness Patterns

Agent管控框架模式

Production AI coding agents are not just an LLM calling tools in a loop. The harness — memory, skills, safety, context control, delegation, and extensibility — is what separates a demo from a production system.

For: Engineers building or extending coding-agent runtimes, custom agents, or advanced multi-agent workflows. Not for: Prompt engineering, model selection, generic software architecture, or LLM API basics.

All principles are distilled from production runtime decisions. Claude Code is used as grounding evidence, not as the only possible implementation.

生产级AI编码Agent并非只是LLM循环调用工具那么简单。管控框架——内存、技能、安全、上下文控制、任务委派和可扩展性——正是区分演示系统与生产系统的核心所在。

适用人群： 构建或扩展编码Agent运行时、自定义Agent，或高级多Agent工作流的工程师。 不适用人群： 提示词工程、模型选型、通用软件架构，或LLM API基础操作相关从业者。

所有原则均提炼自生产环境运行时的决策经验。Claude Code仅作为落地示例参考，并非唯一可行的实现方案。

Choose Your Problem

选择你的场景

If you want to...	Read
Make the agent remember and improve over time	Memory
Package reusable workflows and expertise	Skills
Let the agent use tools powerfully but not dangerously	Tools and Safety
Give the agent the right context at the right cost	Context Engineering
Split work across multiple agents without losing control	Multi-agent Coordination
Extend behavior with hooks, background tasks, or startup logic	Lifecycle and Extensibility

Before you start building: Read the Gotchas — these are the non-obvious failure modes that cost the most time.

如果你想要……	阅读章节
让Agent能够记忆并随时间提升能力	内存
封装可复用的工作流和领域知识	技能
让Agent高效且安全地使用工具	工具与安全
以合理成本为Agent提供合适的上下文	上下文工程
在多个Agent间分配工作且不失控	多Agent协同
通过钩子、后台任务或启动逻辑扩展Agent行为	生命周期与可扩展性

开始构建前： 阅读注意事项——这些是最耗费时间的非显性故障模式。

1. Memory

1. 内存

User problem: "My agent forgets corrections and project rules between sessions."

Golden rule: Separate what the agent knows (instruction memory) from what the agent learns (auto-memory) from what the agent extracts (session memory). Each layer has different persistence, trust, and review needs.

When to use: Any agent that operates across multiple sessions or needs to accumulate project-specific knowledge over time.

How it works:

Instruction memory is curated, hierarchical configuration injected into system context in priority order (org-wide → user → project → local; local wins). This is where project conventions, coding standards, and behavioral rules live. It is human-authored and stable.
Auto-memory is agent-written persistent knowledge with a type taxonomy (user / feedback / project / reference) and a capped index. Saving is two-step: write a topic file, then update the index. The cap prevents unbounded growth — without cleanup, recent entries silently disappear.
Session extraction runs as a background agent at session end. It directly writes to auto-memory — topic file then index — following the same two-step save invariant. A mutual-exclusion guard ensures that if the main agent already wrote memory during the turn, the extractor skips entirely. This is the autonomous learning loop.
Review and promotion audits across all memory layers and proposes cross-layer moves (auto-memory → project conventions, personal instructions, or team memory). It never applies changes autonomously — proposals require explicit user approval.

Start here: Define your memory layers (instruction, auto, extraction). Implement the two-step save invariant (topic file, then index). Add background extraction only after the core write path is stable.

In Claude Code: Use
/remember
to audit and promote auto-memory entries across layers.

Tradeoffs:

More memory layers = richer recall but higher maintenance burden. Without periodic pruning, index caps cause silent data loss.
Session extraction adds latency at session end but dramatically improves cross-session learning.

Go deeper: references/memory-persistence-pattern.md

用户痛点： "我的Agent在会话之间会忘记修正内容和项目规则。"

黄金法则： 将Agent已知的内容（指令内存）、习得的内容（自动内存）和提取的内容（会话内存）分开存储。每个层级的持久化方式、可信度和审核需求各不相同。

适用场景： 需要跨会话运行，或随时间积累项目特定知识的Agent。

实现方式：

指令内存是经过整理的分层配置，按优先级注入系统上下文（组织级 → 用户级 → 项目级 → 本地级；本地级优先级最高）。项目约定、编码标准和行为规则都存储于此。由人工编写，内容稳定。
自动内存是Agent编写的持久化知识，带有类型分类（用户/反馈/项目/参考）和容量上限的索引。保存分为两步：先写入主题文件，再更新索引。容量上限可防止无限制增长——若不清理，最新条目会被静默覆盖。
会话提取在会话结束时由后台Agent执行。它直接写入自动内存——先主题文件，再索引——遵循相同的两步保存规则。互斥锁确保如果主Agent在会话过程中已写入内存，提取器会完全跳过此步骤。这是自主学习循环的核心。
审核与升级会检查所有内存层级，并提出跨层级迁移建议（自动内存 → 项目约定、个人指令或团队内存）。它不会自主应用变更——所有建议都需要用户明确批准。

入门步骤： 定义你的内存层级（指令、自动、提取）。实现两步保存规则（主题文件→索引）。仅在核心写入路径稳定后，再添加后台提取功能。

在Claude Code中： 使用
/remember
命令审核并跨层级升级自动内存条目。

权衡点：

内存层级越多 → 回忆能力越强，但维护负担也越高。若不定期清理，索引容量上限会导致静默数据丢失。
会话提取会在会话结束时增加延迟，但能显著提升跨会话学习能力。

深入阅读： references/memory-persistence-pattern.md

2. Skills

2. 技能

User problem: "I want my agent to reuse workflows and domain knowledge without re-explaining them every time."

Golden rule: Skills are lazy-loaded instruction sets, not eagerly injected prompts. Discovery must be cheap (metadata only); the full body loads only on activation.

When to use: Any agent that needs reusable, composable workflows activating on matching user intent.

How it works:

Discovery is budget-constrained: the agent sees a compact listing of all available skills (name, description, and when-to-use hint concatenated per entry), each hard-capped at a fixed character limit, with the total capped at roughly 1% of the context window. Front-load your trigger language — tails get truncated.
Loading is lazy: only metadata enters the always-on context. The full skill body loads only when the skill activates, keeping idle token cost near zero.
Execution can be inline (shared context) or isolated (forked sub-agent with its own token budget). Isolation prevents a heavy skill from exhausting the parent's context.
Sources can be bundled, user-installed, or dynamically loaded from plugins. Deduplication by canonical path prevents the same skill from appearing twice across overlapping source directories.

Start here: Choose a metadata format (frontmatter recommended). Implement two-phase discovery: cheap listing at startup, lazy body loading on invocation. Set a per-entry character cap before your catalog grows.

Tradeoffs:

Lazy loading saves tokens but adds one round-trip of latency on first activation.
Forked execution provides isolation but loses access to the parent's accumulated context.

Go deeper: references/skill-runtime-pattern.md

用户痛点： "我希望我的Agent能够复用工作流和领域知识，无需每次重新解释。"

黄金法则： 技能是懒加载的指令集，而非预注入的提示词。技能发现必须低成本（仅加载元数据）；仅在激活时才加载完整内容。

适用场景： 需要根据用户意图激活可复用、可组合工作流的Agent。

实现方式：

发现阶段受预算限制：Agent仅能看到所有可用技能的精简列表（每个条目包含名称、描述和适用场景提示），每个条目有固定字符上限，总容量约为上下文窗口的1%。优先展示触发关键词——尾部内容会被截断。
加载阶段采用懒加载：仅元数据会进入常驻上下文。仅在技能激活时才加载完整内容，使空闲状态下的token成本接近零。
执行阶段可选择内联（共享上下文）或隔离（使用独立token预算的子Agent分支）。隔离模式可避免重型技能耗尽父Agent的上下文资源。
技能来源可分为内置、用户安装或从插件动态加载。通过规范路径去重，避免同一技能在重叠目录中重复出现。

入门步骤： 选择元数据格式（推荐使用前置元数据）。实现两阶段发现机制：启动时低成本列出技能，调用时懒加载完整内容。在技能目录增长前设置单条目字符上限。

权衡点：

懒加载节省token，但首次激活时会增加一次往返延迟。
分支执行提供隔离，但无法访问父Agent积累的上下文。

深入阅读： references/skill-runtime-pattern.md

3. Tools and Safety

3. 工具与安全

User problem: "I want my agent to use tools powerfully, but not dangerously."

Golden rule: Default to fail-closed. Tools are serial and gated unless explicitly marked safe for concurrency and approved by the permission pipeline.

When to use: Any agent runtime that needs tool registration, concurrency control, or permission gating.

How it works:

Registration uses fail-closed defaults: tools are non-concurrent and non-read-only unless the developer opts in. This prevents accidental parallel execution of state-mutating operations.
Concurrency classification is per-call, not per-tool: the same tool can be safe for some inputs and unsafe for others. The runtime partitions a batch of tool calls into consecutive groups — safe calls run in parallel, any unsafe call starts a serial segment.
Permission pipeline evaluates rules from multiple sources in strict priority order spanning settings files (user, project, local, flag, and policy), CLI arguments, command-scoped rules, and session grants. The evaluator is stateful — it tracks denials, transforms modes, and updates state as a side effect.
Handler dispatch varies by execution environment: interactive (human prompt), automated (coordinator), or async (swarm agent). The same permission rules feed different approval surfaces.

Start here: Route every tool call through one permission gate. Default to fail-closed (deny/ask). Add bypass-immune rules for protected paths before shipping any auto-approve mode.

In Claude Code: Use
/update-config
to configure permission rules and hooks.

Tradeoffs:

Fail-closed defaults mean new tools are safe out of the box, but developers must actively opt into concurrency — forgetting to flag a read-only tool as concurrent-safe silently degrades throughput.
Multi-source permission layering is powerful but hard to debug when rules from different sources conflict.

Go deeper: references/tool-registry-pattern.md | references/permission-gate-pattern.md

用户痛点： "我希望我的Agent能够高效使用工具，但不会带来安全风险。"

黄金法则： 默认采用故障关闭模式。工具默认按串行方式执行并受权限管控，除非被明确标记为支持并发且通过权限管道审批。

适用场景： 需要工具注册、并发控制或权限管控的Agent运行时。

实现方式：

注册阶段默认故障关闭：工具默认不支持并发且非只读，除非开发者主动开启。这可防止意外并行执行修改状态的操作。
并发分类基于单次调用，而非工具本身：同一工具对某些输入安全，对其他输入可能不安全。运行时会将批量工具调用划分为连续组——安全调用并行执行，任何不安全调用都会启动串行执行段。
权限管道按严格优先级评估来自多源的规则，包括配置文件（用户、项目、本地、标记和策略）、CLI参数、命令范围规则和会话授权。评估器是有状态的——它会跟踪拒绝记录、转换模式并更新状态作为副作用。
处理器调度因执行环境而异：交互式（人工提示）、自动化（协调器）或异步（集群Agent）。相同的权限规则会适配不同的审批场景。

入门步骤： 将所有工具调用路由至同一权限网关。默认采用故障关闭模式（拒绝/询问）。在启用任何自动批准模式前，为受保护路径添加不可绕过的规则。

在Claude Code中： 使用
/update-config
命令配置权限规则和钩子。

权衡点：

故障关闭默认设置使新工具开箱即可用，但开发者必须主动开启并发支持——若忘记将只读工具标记为支持并发，会静默降低吞吐量。
多源权限分层功能强大，但当不同来源的规则冲突时难以调试。

深入阅读： references/tool-registry-pattern.md | references/permission-gate-pattern.md

4. Context Engineering

4. 上下文工程

User problem: "My agent either sees too much, too little, or the wrong thing."

Golden rule: Treat context as a budget, not a dump. Every token in the window should earn its place through one of four operations: select, write, compress, or isolate.

When to use: Any agent whose performance degrades in long sessions, whose delegated work pollutes the parent context, or whose startup is slow due to eager context loading.

How it works:

Select — Load context just-in-time, not all-at-once. Use progressive disclosure with three tiers: metadata (always present, cheap), instructions (loaded on activation), resources (loaded on demand). Memoize expensive context builders and invalidate only at known mutation points — not reactively.
Write — Context is not read-only. The agent writes back to persistent storage: auto-memory entries, background extraction outputs, task state, permission rules. The write-back loop is what turns a stateless agent into a learning system.
Compress — Long sessions exhaust the window. Reactive compaction summarizes older turns mid-session, preserving recent context while reclaiming budget. Mark snapshot data as snapshots so the model knows to re-fetch for current state.
Isolate — Delegated work must not pollute the parent's context. Coordinator workers start with zero context inheritance (only the explicit prompt). Fork children inherit full context but are single-level (no recursive forks). Filesystem-level isolation (worktrees) gives an agent its own working copy.

Start here: Audit your current context cost per turn. Apply hard caps to every variable-length block. Add truncation recovery pointers (tell the model which tool to call for full output) before enabling any compression.

Tradeoffs:

Aggressive caching reduces latency but creates staleness risk — every mutation point must explicitly clear the cache, or the model operates on stale data for the remainder of the session.
Progressive disclosure saves tokens but means the model can't reason about a skill's full capabilities until it's activated.

Go deeper: references/context-engineering-pattern.md (index) | select | compress | isolate

用户痛点： "我的Agent要么看到过多内容，要么内容不足，或者看到错误的内容。"

黄金法则： 将上下文视为预算，而非数据 Dump。上下文窗口中的每个token都必须通过以下四种操作之一证明其价值：选择、写入、压缩或隔离。

适用场景： 长会话中性能下降、委派工作污染父上下文，或因预加载上下文导致启动缓慢的Agent。

实现方式：

选择——按需加载上下文，而非一次性全部加载。采用三级渐进式披露：元数据（始终存在，成本低）、指令（激活时加载）、资源（按需加载）。对昂贵的上下文构建器进行缓存，仅在已知的变更点失效——而非被动失效。
写入——上下文并非只读。Agent会将内容写回持久化存储：自动内存条目、后台提取输出、任务状态、权限规则。写回循环是将无状态Agent转变为学习系统的关键。
压缩——长会话会耗尽上下文窗口。主动压缩会在会话中总结较早的对话回合，保留近期上下文的同时回收预算。将快照数据标记为快照，以便模型知道需要重新获取当前状态。
隔离——委派的工作不得污染父Agent的上下文。协调器Worker启动时不继承任何上下文（仅包含显式提示）。分支子Agent继承完整上下文，但仅支持单层级（不允许递归分支）。文件系统级隔离（工作树）为Agent提供独立的工作副本。

入门步骤： 审核当前每个对话回合的上下文成本。为每个可变长度块设置严格上限。在启用任何压缩功能前，添加截断恢复指针（告知模型调用哪个工具获取完整输出）。

权衡点：

激进缓存减少延迟，但存在数据过期风险——每个变更点必须显式清除缓存，否则模型在整个会话中都会基于过期数据运行。
渐进式披露节省token，但模型在技能激活前无法了解其完整能力。

深入阅读： references/context-engineering-pattern.md (索引) | 选择 | 压缩 | 隔离

5. Multi-agent Coordination

5. 多Agent协同

User problem: "I want parallelism, specialization, and coordination without chaos."

Golden rule: The coordinator must synthesize, not delegate understanding. "Based on your findings, fix it" is an anti-pattern — the coordinator should digest worker results into precise specs before dispatching implementation.

When to use: When a task is too large for a single agent, when you need parallel exploration, or when you want persistent specialized teammates.

How it works:

Three delegation patterns serve different task shapes:

Pattern	Context sharing	Best for
Coordinator	None — workers start fresh	Complex multi-phase tasks (research → synthesize → implement → verify)
Fork	Full — child inherits parent history	Quick parallel splits sharing loaded context
Swarm	Peer-to-peer via shared task list	Long-running independent workstreams

Key constraints:

Fork is single-level only — recursive forks would multiply context cost exponentially.
Swarm teammates cannot spawn other teammates — the roster is flat to prevent uncontrolled growth.
Results arrive asynchronously; fire-and-forget registration returns an ID immediately so the parent can continue working.

Start here: Pick one delegation pattern and implement it fully before mixing patterns. Write every sub-agent prompt as a self-contained document. Add a synthesis step between research and implementation workers — this is where the orchestrator adds value.

Implementation checklist for the coordinator pattern:

Define phased workflow: research → synthesize → implement → verify
Write self-contained prompts for each worker (no "based on your findings")
Filter each worker's tool set to only what it needs
Decide continue-vs-spawn policy: continue if context overlaps, spawn fresh for verification

Tradeoffs:

Coordinator mode is safest but slowest — each phase waits for the previous one.
Fork is fastest but limited to one level and shares the parent's full context cost.
Swarm is most flexible but hardest to coordinate — peers communicate only through a shared task list.

Go deeper: references/agent-orchestration-pattern.md

用户痛点： "我希望实现并行处理、专业化分工和协同工作，同时避免混乱。"

黄金法则： 协调器必须进行综合处理，而非简单委派理解任务。“基于你的发现进行修复”是反模式——协调器应先将Worker的结果整理为精确规范，再分派实现任务。

适用场景： 任务规模超出单个Agent处理能力、需要并行探索，或需要持久化专业协作伙伴的场景。

实现方式：

三种委派模式适用于不同的任务类型：

模式	上下文共享	最佳适用场景
协调器	无——Worker从零开始	复杂多阶段任务（研究 → 综合 → 实现 → 验证）
分支	完整——子Agent继承父Agent历史	需要共享已加载上下文的快速并行拆分任务
集群	通过共享任务列表实现 peer-to-peer 通信	长期运行的独立工作流

关键约束：

分支仅支持单层级——递归分支会使上下文成本呈指数级增长。
集群伙伴无法生成其他伙伴——成员列表为扁平结构，防止无限制增长。
结果异步返回；即发即忘式注册会立即返回ID，以便父Agent继续工作。

入门步骤： 选择一种委派模式并完整实现，再混合使用其他模式。将每个子Agent的提示词编写为独立文档。在研究Worker和实现Worker之间添加综合步骤——这是编排器创造价值的核心环节。

协调器模式实现清单：

定义分阶段工作流：研究 → 综合 → 实现 → 验证
为每个Worker编写独立提示词（避免“基于你的发现”这类表述）
为每个Worker过滤工具集，仅保留必要工具
决定继续执行还是生成新Agent：若上下文重叠则继续执行，验证阶段生成新Agent

权衡点：

协调器模式最安全但速度最慢——每个阶段需等待前一阶段完成。
分支模式最快，但仅支持单层级且共享父Agent的完整上下文成本。
集群模式最灵活，但最难协调——伙伴仅能通过共享任务列表通信。

深入阅读： references/agent-orchestration-pattern.md

6. Lifecycle and Extensibility

6. 生命周期与可扩展性

User problem: "I need hooks, background tasks, and a clean startup sequence."

Golden rule: Extensibility is an injection point, not an inheritance hierarchy. Hooks attach side effects at lifecycle moments; tasks track async work with strict state machines; bootstrap layers initialization sequentially with memoized stages.

When to use: When you need to extend agent behavior without modifying core code, track long-running background work, or structure initialization across multiple entry modes.

How it works:

Hooks extend behavior by attaching side effects at defined lifecycle moments (pre/post tool execution, prompt submission, agent start/end). Trust is all-or-nothing: if the workspace is untrusted, all hooks skip — not just suspicious ones. Session-scoped hooks are ephemeral and cleaned on session end.
Long-running work is tracked via typed state machines. Each work unit gets a typed, prefixed ID, a strict lifecycle (running → completed / failed / killed), and disk-backed output. Eviction is two-phase: disk output cleaned eagerly at terminal state, in-memory records cleaned lazily after the parent has been notified.
Bootstrap structures initialization as dependency-ordered, memoized stages. The trust boundary — the point where the user grants consent — is the critical inflection: security-sensitive subsystems (telemetry, secret environment variables) must not activate before trust is established. Multiple entry modes (CLI, server, SDK) share the same bootstrap path with different entrypoints.

Start here: Route all hooks through a single dispatch point. Implement the trust gate before adding any external hook type. Register cleanup handlers during init, not at usage sites.

In Claude Code: Use
/update-config
to configure hooks (pre/post tool execution, prompt submission).

Tradeoffs:

All-or-nothing hook trust is simple but coarse — one untrusted hook disables the entire extension system.
Disk-backed task output keeps memory constant but adds I/O latency proportional to concurrent work units.

Go deeper: references/hook-lifecycle-pattern.md | references/task-decomposition-pattern.md | references/bootstrap-sequence-pattern.md

用户痛点： "我需要钩子、后台任务和清晰的启动序列。"

黄金法则： 可扩展性是注入点，而非继承层级。钩子在生命周期节点附加副作用；任务通过严格状态机跟踪异步工作；启动引导按依赖顺序分阶段初始化，并对阶段进行缓存。

适用场景： 需要在不修改核心代码的情况下扩展Agent行为、跟踪长期后台工作，或在多种入口模式下结构化初始化的场景。

实现方式：

钩子通过在定义好的生命周期节点（工具执行前后、提示词提交、Agent启动/结束）附加副作用来扩展行为。信任是全有或全无的：若工作区不可信，所有钩子都会跳过——而非仅跳过可疑钩子。会话级钩子是临时的，会话结束时会被清理。
长期运行任务通过类型化状态机跟踪。每个任务单元会获得一个带前缀的类型化ID、严格的生命周期（运行中 → 完成/失败/终止）和磁盘存储的输出。回收分为两个阶段：终端状态下立即清理磁盘输出，父Agent收到通知后延迟清理内存记录。
启动引导将初始化为按依赖顺序排列的缓存阶段。信任边界——用户授予权限的节点——是关键转折点：安全敏感子系统（遥测、秘密环境变量）在信任建立前不得激活。多种入口模式（CLI、服务器、SDK）共享相同的启动引导路径，仅入口点不同。

入门步骤： 将所有钩子路由至同一调度点。在添加任何外部钩子类型前实现信任网关。在初始化阶段注册清理处理程序，而非在使用节点注册。

在Claude Code中： 使用
/update-config
命令配置钩子（工具执行前后、提示词提交）。

权衡点：

全有或全无的钩子信任机制简单但粗糙——一个不可信钩子会禁用整个扩展系统。
磁盘存储任务输出保持内存占用稳定，但会增加与并发任务数量成正比的I/O延迟。

深入阅读： references/hook-lifecycle-pattern.md | references/task-decomposition-pattern.md | references/bootstrap-sequence-pattern.md

Gotchas

注意事项

Non-obvious principles that will cause bugs if you violate them:

Concurrency classification is per-call, not per-tool. A tool may be safe for some inputs and unsafe for others. Don't assume a tool's concurrency behavior is static — the runtime decides per invocation.
Permission evaluation has side effects. The permission checker tracks denials, transforms modes, and updates state. Don't treat it as a pure lookup function.
Most async work skips the "pending" state. In practice, work units register directly as "running." Don't build UIs that assume every work unit starts pending.
Fork children must not fork. The recursive guard preserves a single-level invariant. The fork tool stays in the child's tool pool (for prompt cache sharing) but is blocked at call time.
Context builders are memoized but manually invalidated. Add a context source without adding a corresponding invalidation point, and the model sees stale data for the entire session.
Memory indexes have hard caps. Entries beyond the cap are silently truncated. Without periodic cleanup, recent entries become invisible.
Skill listing budgets are tight. Descriptions are concatenated and capped per entry. Front-load the most distinctive trigger language — the tail gets cut.
Hook trust is all-or-nothing. If the workspace is untrusted, the entire hook system is disabled, not just individual suspicious hooks.
The default permission for tools is "allow." Tools that don't implement custom permission logic delegate entirely to the rule-based system. Override only when you need tool-specific gates (path ACLs, quotas, etc.).
Eviction requires notification. A terminal work unit is only GC-eligible after the parent has received the completion signal. Evicting before notification creates a race where the parent can never read the result.

若违反以下非显性原则，会导致Bug：

并发分类基于单次调用，而非工具本身。 工具可能对某些输入安全，对其他输入不安全。不要假设工具的并发行为是静态的——运行时会针对每次调用做出决策。
权限评估存在副作用。 权限检查器会跟踪拒绝记录、转换模式并更新状态。不要将其视为纯查询函数。
大多数异步工作跳过“待处理”状态。 实际上，任务单元会直接注册为“运行中”。不要构建假设每个任务单元都从待处理状态开始的UI。
分支子Agent不得再次分支。 递归防护确保单层级不变量。分支工具会保留在子Agent的工具池中（用于提示词缓存共享），但调用时会被阻止。
上下文构建器会被缓存但需手动失效。 添加上下文源但未添加对应的失效点，会导致模型在整个会话中都看到过期数据。
内存索引有严格容量上限。 超出上限的条目会被静默截断。若不定期清理，最新条目会变得不可见。
技能列表预算紧张。 描述内容会被拼接且单条目有容量上限。优先展示最具辨识度的触发关键词——尾部内容会被截断。
钩子信任是全有或全无的。 若工作区不可信，整个钩子系统都会被禁用，而非仅禁用单个可疑钩子。
工具的默认权限是“允许”。 未实现自定义权限逻辑的工具会完全委托给基于规则的系统。仅在需要工具特定网关（路径ACL、配额等）时才覆盖默认设置。
回收任务需先通知。 终端状态的任务单元仅在父Agent收到完成信号后才符合GC条件。在通知前回收会导致父Agent永远无法读取结果的竞争条件。

When NOT to Use This Skill

不适用场景

This skill is about the harness around an agent, not:

Prompt engineering or system prompt design
Model selection or fine-tuning
Generic software architecture (MVC, microservices)
Chat UIs or conversational interfaces
LLM API integration basics

If your question is about the model itself rather than the system around it, this skill does not apply.

本技能聚焦于Agent的管控框架，不涉及：

提示词工程或系统提示词设计
模型选型或微调
通用软件架构（MVC、微服务）
聊天UI或对话界面
LLM API集成基础

若你的问题聚焦于模型本身而非其周边系统，本技能不适用。