Unit 3 | Core Architecture

Agent Platform Logic & Human Review

Agent 平台邏輯與人審機制

Enterprise AI agents work best with a clear execution loop and limited room for open-ended chat. In this unit, you will learn the minimum structure of a reliable agent platform, the role of data guardrails, and a simple handoff brief for cross-team work.

企業級 AI Agent 不能只靠開放式聊天，而需要清楚的執行迴圈。本單元會帶你掌握可靠 Agent 平台的最小構造、資料防護欄的角色，以及跨團隊協作時可使用的簡易交接簡報。

Core Concept

核心觀念

An AI Agent maps goals to actions. For business use, model answers are only one part of the issue. The design also needs clear reasoning boundaries, checks, and review points.

AI Agent 會把目標轉化為行動。用在商業情境時，模型回答只是其中一部分；設計上還要處理推理邊界、檢查方式與審核點。

Class Output

關鍵產出

By the end of this unit, you will complete an Agent Platform Definition Table and draft a short HANDOFF.md-style brief that explains the idea to another team.

本單元結束時，你會完成一張 Agent 平台定義表，並草擬一份簡短的 HANDOFF.md 式交接簡報，讓其他團隊看得懂你的設計。

Architecture Design

The Minimum Structure of an Agent Platform

Agent 平台的最小運作構造

To move from prompt testing to business use, view the Agent as a managed workflow with more structure than a chatbot. A practical Agent platform has seven components that work together in a predictable loop.

要從提示詞測試走向商業應用，可以把 Agent 視為一條受管理的工作流程，並加入比聊天框更完整的結構。實用的 Agent 平台由七個組件構成，並在可預測的迴圈中協同運作。

1. Goal (目標)

1. 目標 (Goal)

Defines the business objective and operating boundaries. A fuzzy goal causes model drift, so the brief should also state what the agent should not do.

界定業務目的與運作邊界。含糊的目標會導致指令漂移，因此簡報中也要寫清楚 Agent 不應該做哪些事。

2. Data (資料)

2. 資料 (Data)

The input sources, both static documents (specs, policies) and dynamic contexts (tickets, APIs). Ensures data cleanliness because poor data quality directly leads to hallucination.

輸入資訊源，包含靜態文件（規格書、政策）與動態上下文（工單、API）。確保資料潔淨度，因為低劣的輸入品質會直接導致幻覺。

3. Judgment (判斷)

3. 判斷 (Judgment)

The reasoning logic, filtering policies, and decision matrices. Implemented via prompts, classification chains, or semantic evaluation to guide how inputs are processed.

推理邏輯、過濾規則與決策矩陣。透過提示詞、分類鏈或語意評估來實現，藉此引導 Agent 如何處理輸入資訊。

4. Tools (工具)

4. 工具 (Tools)

External APIs, web search components, calculators, or MCP servers that extend the agent's memory. Tools supply live data so the agent can read facts before it forms an answer.

延伸 Agent 能力的外部 API、網頁搜尋、計算機或 MCP 伺服器。工具提供即時資訊，使 Agent 能讀取真實數據而非憑空猜測。

5. Action (行動)

5. 行動 (Action)

The concrete outcome generated after a decision, such as updating a record, preparing a PDF, or sending a notification. Clear action boundaries help prevent unintended downstream effects.

決策之後產生的具體結果，例如更新紀錄、準備 PDF 或發出通知。行動需要清楚邊界，避免自動化造成非預期的下游影響。

6. Record (紀錄)

6. 紀錄 (Record)

The trail of prompts, decisions, tool calls, costs, and final outputs. Good records help the team review mistakes, explain decisions, and improve the workflow over time.

紀錄提示詞、判斷、工具呼叫、成本與最後產出。好的紀錄能協助團隊回看錯誤、說明決策，並逐步改善流程。

7. Review (人工審核)

7. 人工審核 (Review)

The human-in-the-loop authorization gate. Pauses execution on critical steps (e.g., final delivery, payments) for a supervisor to check and sign off, eliminating rogue actions.

人機協同的授權關卡。在關鍵步驟（如最終交付、付款）暫停執行，交由人類主管審查並核准，以杜絕異常操作。

Risk Control & Governance

Data Guardrails & Human-in-the-Loop

資料防護欄與人機協同審查機制

Automating processes without safety mechanisms introduces severe legal, operational, and financial risks. We deploy dual defense layers: programmatic Data Guardrails and organizational Human-in-the-Loop (HITL) checkpoints.

在缺乏安全機制的狀況下進行自動化，會帶來嚴重的法規、營運與財務風險。我們部署雙重防禦：程式面的「資料防護欄」與組織面的「人機協同審核（HITL）」節點。

I. Data Guardrails (資料防護欄)

一、 資料防護欄 (Data Guardrails)

Guardrails are rule layers around the LLM's inputs and outputs. They help keep the interaction safe, structured, and aligned with company policy.

防護欄是放在 LLM 輸入與輸出周圍的規則層，用來讓互動內容保持安全、結構清楚，並符合公司政策。

  • Input Guardrails: 輸入防護欄： Strips Personally Identifiable Information (PII) before it leaves the enterprise network, blocks malicious prompt injections, and discards out-of-scope customer documents. 在資料離開企業網路前進行敏感個人識別資訊（PII）去識別化、阻擋惡意提示詞注入，並排除超出業務範圍的客戶文件。
  • Output Guardrails: 輸出防護欄： Validates output structure (e.g. JSON schemas), checks for hallucinated links, filters out off-brand language, and ensures compliance with industry regulations. 驗證輸出格式（如符合 JSON 綱要）、檢查虛構連結、過濾偏離品牌基調的措詞，並確保符合產業合規規範。

II. Human-in-the-Loop Review (人工審核節點)

二、 人機協同審查節點 (Human-in-the-Loop)

Complete autonomy is rarely appropriate. The team should identify risk thresholds where the Agent pauses and asks a person to review the case.

完全自主運作在商業場景中十分罕見。我們需要定義風險閾值，在達標時強制作業暫停並交回人工決策。

  • Gated Actions: 攔截型行動： Any task involving high financial value (e.g. refund approvals > $100), direct email communications with key accounts, important record updates, or changes to a live workflow. 涉及高價值資金操作（如大於 $100 美元的退款審核）、直接與重要客戶進行信件往來、重要紀錄更新，或會影響正式流程的變更。
  • Verification Interface: 審查介面設計： Managers need clear comparison views showing: Source context (What the data says), Agent proposal (What the model recommends), and explanation metrics (Why the agent decided this). 審查人員需要清晰的對照視窗，包括：原始上下文（資料來源）、Agent 的提案內容（模型建議）以及推理邏輯說明（為何如此決策）。
Workflow map showing data, rules, process steps, and outputs
Figure 3.1: A Shared Map for Auditable AI Workflows 圖 3.1：可查核 AI 工作流程的共用地圖

A useful workflow map makes the data source, rule layer, process path, and final output visible on the same page. Managers can use this view to decide where API calls should be logged and where human review must pause execution before any final write-back.

好的工作流程圖會把資料來源、規則層、處理路徑與最終輸出放在同一張圖上。管理者可以用這個視角判斷哪些 API 呼叫需要留下紀錄，以及哪些節點應先暫停、交由人工審查，再進行最終寫入。

Management Takeaway: Design for Pause

管理思維：為「暫停」而設計

A common mistake is designing AI systems that try to handle 100% of the process automatically. High-performing systems aim for 80% automated triage, routing the remaining 20% of anomalous or high-risk cases to a dedicated human queue.

常見的錯誤是試圖設計 100% 全自動處理的 AI 系統。高效率的架構通常設定 80% 自動處理與分流，並將其餘 20% 的異常值或高風險案件導向人類主管的待審佇列中。

Enterprise Delivery

The HANDOFF.md Framework

HANDOFF.md 專案交接框架

AI agent settings are often scattered across chat histories, files, and informal notes. A HANDOFF.md-style brief collects the key decisions in one readable document: purpose, data, rules, review points, and expected outputs.

AI Agent 的設定常散在聊天紀錄、檔案與零散備註中。HANDOFF.md 式簡報會把重要決策收在同一份可閱讀文件裡：目的、資料、規則、審查點與預期輸出。

ChatGPT Project sources showing prompt and files organization
Figure 3.2: Context Packaging in ChatGPT Projects 圖 3.2：ChatGPT Projects 中的脈絡打包機制

By keeping rules, glossary files, and sample notes inside one project workspace, the team creates a shared reference point that others can inspect later.

把規則、術語對照表與範例紀錄放在同一個專案工作區，團隊就能建立一個之後可回頭查看的共同參考點。

What to Include in the Handoff Brief

交接簡報應包含哪些內容

When you explain an Agent idea to another team or vendor, include three kinds of material:

當你要把 Agent 構想說明給其他團隊或外部供應商時，可以準備三類材料：

  1. System Instructions (Instructions.txt): 系統指令集 (Instructions.txt)： The raw prompt containing the role, operational scope, formatting constraints, and reasoning protocols. 包含角色設定、業務範圍、格式限制與推理協議的原始提示詞檔案。
  2. Knowledge Context (Knowledge/): 知識庫脈絡 (Knowledge/)： Reference data, database structures, business glossaries, or mock input files that the agent uses for search and analysis. Agent 檢索與分析所使用的參考資料、資料庫結構定義、專有名詞對照表或模擬輸入檔案。
  3. Delivery Blueprint (HANDOFF.md): 交付藍圖 (HANDOFF.md)： The governance document outlining system connections, risk policies, human review triggers, and unit tests. 概述系統連接方式、風險政策、人工審核觸發點與單元測試的治理文件。

Standard HANDOFF.md Markdown Template

標準 HANDOFF.md 標記語法範本

Use this template as a thinking aid. It helps you describe business rules, data boundaries, review triggers, and acceptance examples in a form that teammates can discuss.

這份範本可作為思考輔助，協助你用團隊能討論的方式，寫出業務規則、資料邊界、審查觸發點與驗收範例。

# Agent Project Handoff: [Agent Name]

## 1. System Metadata & Context / 系統基本資訊與業務背景
- **Owner / 專案負責人**: [Name / Department]
- **Target LLM / 目標語言模型**: [e.g., GPT-4o, Gemini 1.5 Pro]
- **Business Process / 業務流程**: [Describe the workflow being automated]
- **Value Metric / 價值指標**: [e.g., Reduce triage time by 40%]

## 2. Core Instructions & Constraints / 核心指令集與運作約束
- **Reference Instruction File / 參考指令檔**: `instructions.txt`
- **Strict Boundaries / 嚴格邊界**:
  1. Do NOT write directly to the production CRM database. (不可直接寫入正式環境 CRM 資料庫。)
  2. Route pricing promises beyond a 10% discount to human review. (超過九折的定價承諾需交由人工審查。)

## 3. Data Inputs & Outputs / 輸入與輸出資料格式定義
- **Input Data Format / 輸入資料格式**:
  - Format: JSON (包含 `customer_id`, `ticket_content`, `sentiment_score`)
- **Output Schema / 輸出格式規範**:
  - Required fields: `priority_tier` (Low/Medium/High), `suggested_reply` (text)

## 4. Human Review Nodes / 人工審查機制與觸發門檻
Route the case to human review when: (需要交由人工審查的條件：)
- **Trigger A**: Suggested refund value > $100 USD. (建議退款金額超過 $100 美元。)
- **Trigger B**: Customer sentiment score falls below 0.2 (High frustration). (客戶情緒分數低於 0.2，表示極度挫折。)
- **Approval Protocol / 審查程序**:
  - Staff reviews the draft, clicks "Approve" to send email, or edits the draft before manual dispatch. (人員審視草稿，點擊「核准」以發送郵件，或在手動寄出前編輯草稿。)

## 5. Verification Cases / 測試與驗收指標
| Input / 輸入 | Expected Agent Output / 預期 Agent 輸出 | Expected Review Route / 預期審查路徑 |
| :--- | :--- | :--- |
| "Order arrived damaged, request refund of $150." | Refund logic triggered with value $150. | GATED (Requires Human Approval) / 需人工核准 |
| "Just checking status of my package." | General reply with tracking URL. | AUTO-DISPATCH (No review needed) / 自動分發 |
← Back to Unit 2 Go to Case Study →