oc-agent-forge

原文涵盖的主题

• Agent Forge
• /oc-agent — Command Reference
• Tri-Agent Architecture
• Why Three Agents for an Agent?
• Phase 1: Agent Planner (/oc-agent plan)
• Planner Persona
• Planner Workflow
• Agent-Topology Decision Tree

On first invocation, read references/orchestrator.md and follow its welcome protocol (if present; otherwise fall back to the shared skills/orchestrator.md). Tri-agent build harness for Claude Agent SDK apps: the Planner decides the agent topology (single-agent vs orchestrator-worker vs pipeline vs hierarchical), the tool budget, and the harness loop shape → the Builder materialises the harness, tool allowlist, and termination logic against the Claude Agent SDK → the Evaluator runs the agent against a task fixture suite, grading from the fixtures and the live run alone, and gates it on task-success / trajectory / tool-efficiency thresholds. An agent is not "give the model some tools and a while-loop." Every default — how many subagents, which tools are in the allowlist, when the loop stops, how much context is carried turn-to-turn — moves a measurable number: task success, token cost, tool-call count, or wall-clock latency. The only honest way to set those defaults is to run the agent against fixtures and score the trajectory. This skill exists to make the agent harness an evaluated artifact, not a vibe. This is the agent-harness counterpart to oc-claude-api. Model routing — which m

这里只展示节选，请以完整原文和当前要求为准。