情境化商業分析：市場、競爭、商業模式與領域指標 Part 03｜不是產出越多越好：如何衡量 People、Engineering 與 AI Agent 的品質、可靠性與成本

每月營運會議裡，最危險的畫面有時不是紅燈，而是一排綠燈。

每位員工處理的工作變多了。工程團隊部署得更頻繁。AI Agent 完成的任務數增加，而且每次請求的平均成本還下降。

三個數字都往「好」的方向走，很容易被一起翻譯成「生產力提升」。問題是，它們可能同時掩蓋三種完全不同的惡化：人變少後剩下的人把缺口扛起來；軟體交付更快，但失敗、重工和服務不穩也跟著上升；Agent 回覆「完成」，實際上該寫進系統的資料根本沒寫進去。

所以這篇不打算找一個可以同時衡量人、工程團隊與 AI Agent 的萬用 KPI。比較值得做的是先弄清楚：每一種工作系統，什麼情況下才有資格把「更多產出」解讀成「表現更好」。

KPI 算之前，先確認這個數字到底在量誰

很多指標不是算錯，而是比較錯。

「每人產出」裡的「人」，可能是全職員工、所有受僱者，或只包含某一類角色；deployment frequency 上升，如果前後比較的不是同一個服務、同一種工作負載，差異未必有意義；Agent success rate 也一樣，測試集若從困難任務換成簡單任務，即使公式完全相同，數字也不能直接拿來說系統進步了。

這裡可以先替每個指標補一份 Metric Contract。這不是某個機構發布的正式標準，而是本文用來約束比較條件的實務做法。至少要知道：

量的是一個人、角色、團隊、服務、software change，還是一個 task / trial；
分母怎麼定義；
前後期的母體或 workload 有沒有變；
不同角色、產品、服務或任務難度有沒有被混在一起；
時間區間與測量方法是否一致；
最後這個數字是要拿來決定擴張、改善、控風險，還是資源配置。

DORA 在 software delivery metrics 的說明裡也提醒，跨不同應用或服務做沒有上下文的比較可能造成誤導，把指標直接變成目標也可能誘發 gaming。這類問題放到 People 或 AI 一樣存在，只是變形方式不同。

People：漂亮的「每人產出」，有時只是分母縮得比較快

假設公司裁了一批人，接下來幾季營收還撐在原本水位，revenue per employee 自然會上升。這個比例可以拿來看公司層級的效率結構，但不能順手推成「每個員工都變得更有效率」。

如果同一段時間關鍵人才離開、自願離職率上升，或剩下的團隊靠長工時把缺口吞下去，比例變漂亮並沒有告訴你組織是不是更健康。它只告訴你一個 aggregate ratio 變了。

ISO 30414:2025 對 human capital reporting 的涵蓋範圍本來就不是單一產出指標，還包括 workforce composition、成本、生產力、健康與福祉、領導與文化、招募、流動與接班、turnover、技能與能力等。放在一起看，People metrics 的管理問題會比較接近「組織還有沒有能力把重要工作做完，而且這個狀態能不能維持」，而不是誰做得更多。

人口定義也很重要。招聘速度若把所有職位混在一起，可能把真正難補的關鍵職缺洗掉；turnover 用期初 headcount、平均 headcount 或某個人才群當分母，得到的管理含義也不同；skills coverage 如果沒有先說是全公司還是特定關鍵能力，數字很難解讀。

Engagement、well-being 這些訊號值得看，但也不要反過來犯另一個錯誤，把它們直接寫成「一定帶來更高利潤」。沒有適當的因果設計，最多只能說它們是組織健康的一部分證據。

Engineering：部署次數很好算，工程表現沒那麼好算

工程團隊很容易被一個數字綁住，尤其是速度。

DORA 目前用五個 software delivery metrics 來描述交付表現：change lead time、deployment frequency、failed deployment recovery time、change fail rate，以及 deployment rework rate。這五個指標把 flow、失敗、恢復與重工放在一起，比只數部署次數完整得多，但它們的範圍仍是 software delivery performance，不是整套 developer productivity 的總分。

一個團隊把 deployment frequency 拉高一倍，如果 change failure 和 rework 同時增加，核心服務又一直 miss SLO，很難說「工程生產力翻倍」。這裡真正需要的是把幾種不同訊號疊在一起看。

SPACE framework 把 developer productivity 視為多維問題，正好補上「活動量不等於整體表現」這個缺口。Google SRE 的 SLI / SLO / error budget 又處理另一件事：可靠性到底要怎麼落到使用者真正感受到的服務行為，以及團隊願意拿多少 reliability headroom 去換取更快的變更。

Security 更不能靠一個 raw vulnerability count 排名。NIST Secure Software Development Framework 是用風險導向的 practices 與 outcomes 組織安全開發；掃描範圍、系統複雜度、曝險面與修補流程一變，漏洞數的意義也跟著變。

所以工程這一塊，我會把交付流速、穩定性與可靠性、風險，以及 developer experience 分開看。哪些地方該快、哪些地方不能出事，本來就不是同一個問題。

AI Agent：先驗證結果，再相信它說自己做完了

AI Agent 的麻煩更直接。它可能搜尋、呼叫工具、讀寫系統，最後給你一個非常像「成功」的答案，但真正的工作成果存在系統裡，不存在它的文字裡。

訂位就是很好理解的例子。Agent 回覆「已成功預約」，真正該驗證的是 reservation 是否存在於 system of record，而不是那句話寫得多有把握。

Anthropic 在 agent eval 的方法裡把 task、trial、grader、transcript / trace 與 outcome 分開。這個拆法的價值在於，過程與結果不會被揉成一個 success flag：Agent 做了什麼、哪一步出錯、環境最後有沒有到達正確 end state，都可以分開判定。

而且一次跑成功還不夠。AI 系統有隨機性，一次成功只能證明這一次成功；要談可靠性，就得做 repeated trials，並區分「至少有一次能成功」和「多次都能穩定成功」。兩者在 production 裡不是同一件事。

RAGAS 這類框架可以拆解檢索與生成品質；GAIA 這類 benchmark 則能測多步推理與工具使用。它們都提供有用的能力證據，但 benchmark 高分仍不能直接回答「這個 Agent 放進我們實際的工作負載後，值不值得擴張」。到了真實運行，還要看回應延遲、一次任務走了幾輪、呼叫多少次工具、用了多少 token，以及錯誤率、重試、fallback 和需要人工接手的頻率；安全、隱私與政策風險也要一起納入。NIST 的 Generative AI Profile 同樣把 GenAI 放進更完整的風險與可信任性生命週期裡評估。

三種工作不能共用 KPI，但可以共用一套問法

People、Engineering、AI Agent 的工作單位、失敗方式與成本分母都不同。硬把它們放進同一張「生產力排行榜」，比較出來的通常只是三個名字都叫 productivity 的不同東西。

下面六層是本文整理出的 measurement grammar，是作者為了跨領域比較而做的 synthesis，不是 ISO、DORA、NIST 或其他機構共同發布的標準。

Measurement layer	People	Engineering	AI Agent
Outcome	能力、留任，以及可合理歸因的組織／業務結果	使用者／業務結果與成功交付	可驗證的 task / end-state success
Flow / Capacity	招募、內部流動、可用產能	lead time、deployment flow	throughput、turns、tool steps
Quality / Reliability	品質、留任、組織健康訊號	failure、recovery、SLO、incidents	correctness、grounding、重複試驗的一致性
Economics	人力與招募成本，但要搭配合理分母	工程、infra、tool 成本，搭配穩定 workload	token、tool、runtime 成本，按 task 或 verified success 解讀
Guardrails	well-being、fairness、privacy、culture	security、reliability、developer experience	safety、security、privacy、policy、human escalation
Context Contract	role、population、window、method	service、change、workload、window	task、workflow、trial、distribution、window

共用的是測量順序，不是指標名稱。People 的 retention rate 沒有理由跟 Engineering 的 change fail rate 比高低；deployment frequency 也不能跟 Agent throughput 排名。真正可以反覆使用的是幾個檢查：有用結果有沒有增加、品質與可靠性有沒有守住、成本怎麼變、邊界有沒有被突破，以及前後兩期究竟還能不能比較。

這也是「Context before benchmark」的意思。Benchmark 可以用，但先確認兩邊量的是同一類東西。

People、Engineering 與 AI Agent 使用不同指標，但共同檢查 Outcome、Flow / Capacity、Quality / Reliability、Economics、Guardrails 與 Context Contract 六個衡量問題。

共同的是衡量問題，不是跨領域可直接比較的生產力分數；每個工作系統仍需要自己的指標。

成本很重要，但便宜要建立在成功之上

AI 最容易出現一種漂亮但危險的效率故事：cost per request 下降，所以系統變划算了。

如果每次請求雖然更便宜，卻同時帶來更多失敗、重試、fallback 或人工接手，這個結論可能剛好相反。為了把成本重新拉回有用結果，可以使用一個簡單的管理型 heuristic：

Cost per successful task = 可歸屬的 Agent / model / tool / runtime 成本 ÷ 經驗證成功的任務數

它不是業界標準公式。使用前仍要先定義什麼叫「任務成功」，以及成本邊界畫在哪裡：重試要不要算、工具與基礎設施費用算到哪裡、fallback 或人工處理是否納入；還要確認前後兩期的工作負載分布是否足夠穩定，才適合比較。

同一個原則可以延伸到 People 與 Engineering，但不需要硬套成相同公式。成本如果脫離 outcome 與品質門檻，很容易把「省到錢」誤認成「系統更有效」。Agent 每次請求更便宜，如果 verified success 掉得更快，最後每個成功任務反而可能更貴。

產出先通過 Verified outcome、Quality / Reliability、Economics、Guardrails 與 Context，再決定 Scale、Redesign、Constrain 或 Investigate；Cost per successful task 僅作管理型 heuristic。

產出更多或單次請求更便宜都不足以支持擴張；管理決策仍要看成功結果、可靠性、經濟性、風險與可比情境。

綠燈出現之後，真正要選的是動作

回到月度營運會議。三個產出數字都變好時，我會先問五件事：結果是否真的改善；品質或可靠性是否守住；成本改善是不是發生在相同的 Metric Contract 下；安全、隱私、well-being 等 guardrails 有沒有被突破；以及前後比較的 population、service、task distribution 或測量方法是否已經改變。

答案不同，下一步也不同。

結果與品質都站得住，成本也改善，才有理由 Scale。
結果有價值但流程或可靠性有問題，先 Redesign。
Guardrail 被突破，就算產出很好看也要 Constrain。
如果連前後兩期能不能比較都不確定，先 Investigate。

這四個動作比「哪個 KPI 最重要」更接近管理者真的要做的事。人、工程團隊與 AI Agent 不需要共享同一個 productivity score；先確認各自的 measurement architecture 成立，再看那些數字有沒有資格被放進同一場決策裡。