今天的範例同樣以 SequentialOrchestration 為主題，但這次我們將應用在 合約內容審查 上。合約是許多企業日常運營中不可或缺的一部分，確保合約內容的文字精準性和風險責任評估對於企業風險管理是非常重要。那麼擅長文字表達的 LLM 是否可以協助我們進行合約內容的審查呢？答案是肯定的！具體實作上可以設計一個多代理人系統，讓不同專業領域的 Agent 依序審查合約內容，並產出審查報告。
場景：設計一個包含三個審查階段的系統，展示如何使用 SequentialOrchestration 編排系統來管理多個代理人，並依序完成合約內容的多方面審查。
(實務上當然需要更詳細的檢核規則，這裡的範例提供概念性的實作)
— 階段一：合約內容文字審查 Agent
職責：審查合約內容的文字表達是否清晰、無歧義、模糊不清的用語或是潛在的灰色地帶
— 階段二：法律風險評估審查 Agent
職責：評估合約內容可能帶來的法律風險，包括不平等條款、責任限制等
— 階段三：合約修正建議審查 Agent
職責：根據前兩個階段的審查意見，提出合約內容的修正建議
實際上可以根據需求增加更多專業領域的審查 Agent，例如財務風險評估 Agent、合規審查 Agent 等等。
首先，需要建立三個專責代理人 (ChatCompletionAgent)，每個代理人負責不同的審查階段。
ReviewAgent，合約內容文字審查員：var reviewAgent = new ChatCompletionAgent()
{
Kernel = kernel,
Name = "ContentReviewAgent",
Description = "合約內容文字審查員",
Instructions =
"""
你是合約審查專家，任務是針對合約內容的文字進行審查。
你將會收到一份合約內容，請針對以下要點協助確認合約內容是否合適
## 合約內容審查要點：
- 文字表達是否清晰
- 是否有潛在的歧義或誤解
- 模糊不清的用語
- 可能產生爭議的灰色地帶
若有疑慮請給出建議或補充意見，若是合規則請在審查意見中回覆「合規」。
## 輸出格式：
[合約內容]
...（合約）
[內容文字審查意見]
- 片段：…（合約片段）
建議：...（審查意見)
"""
};
RiskAgent，法律風險評估審查員：var riskAgent = new ChatCompletionAgent()
{
Kernel = kernel,
Name = "InequalityRiskAgent",
Description = "合約不平等風險審查員",
Instructions =
"""
你是合約不平等風險審查專家，任務是評估合約內容可能帶來的法律風險，包括不平等條款、責任限制等。
你將會收到一份合約以及合約內容文字審查的審查意見（若有）。請保留所有既有意見內容，再加上你的審查意見，不可刪除任何意見。
## 合約不平等風險審查要點：
- 單方面解釋權
- 過度的違約金或懲罰性條款
- 不合理的責任限制
若有疑慮請給出建議或補充意見，若是合規則請在審查意見中回覆「合規」。
## 輸出格式：
[合約內容文字審查意見]
....(保留文字內容審查意見內容)
[合約不平等風險審查意見]
- 片段：…（合約片段）
風險：…（風險描述）
建議：…（審查意見）
"""
};
FixProposalAgent，合約修正建議審查員：var fixProposalAgent = new ChatCompletionAgent()
{
Kernel = kernel,
Name = "FixProposalAgent",
Description = "合約修正建議審查員",
Instructions =
"""
你是合約修正文案助手。
你將會收到一份原始合約內容以及前面部門的審查意見（若有）。
請保留所有既有意見內容，並在最後產出你根據合約內容所提出的修正後合約內容，不可刪除任何意見。
# 最終報告
## 文字內容審查意見
....
## 合約不平等風險審查意見
....
## 修正後合約內容（最終報告）
...（修正後合約）
"""
};
接著，將這三個代理人組合成一個 SequentialOrchestration 編排系統，按照順序，讓他們依序完成審查任務。
// Define the orchestration
SequentialOrchestration orchestration =
new(reviewAgent, riskAgent, fixProposalAgent)
{
Name = "ContractReviewOrchestration",
Description = "多代理人協同審查合約內容，確保合約文字表達以及風險控制。"
};
再次提醒，所有變數都必須是在 InProcessRuntime 啟動後建立。
// 建立協作流程物件 (這裡要注意的是所有變數都必須是在InProcessRuntime 啟動後建立)
InProcessRuntime runtime = new();
await runtime.StartAsync();
模擬執行一份合約內容來測試整個多代理人協同審查系統。
string input =
"""
### 以下是合約內容，我司為乙方：
BPM系統建置服務合作協議
甲方：有料股份有限公司
乙方：錢多多科技有限公司（以下稱「乙方」）
生效日：簽署日當日生效
第一條 服務範圍：
1. 乙方原則上提供「系統」及相關之建置、維運、顧問等服務（以下合稱「本服務」）；「系統」之範圍包含但不限於流程、平台、工具及其他視情況需要之組件，實際內容以雙方後續往來之任何文字、口頭或默示同意為準。
2. 本服務之具體項目應大致符合甲方當時需求；若甲方認為有必要，得要求乙方適度調整與擴充，乙方應不遲延完成合理之部分。至於何謂「合理」，由甲方依個案衡量。
3. 乙方應以商業上可行之最佳努力完成交付；必要時得委由適當第三人處理（是否需告知甲方，依案件緊急程度而定）。
4. 技術規格與細節原則上以甲方內部文件或慣例為準；如未能及時提供，乙方得以通行作法或其專業判斷先行辦理，事後再行確認。
5. 如雙方對前述定義有理解歧異，優先依本條第2款及附件A（如有）之規定處理；附件A未附時，由甲方之記錄或郵件摘要供參考。
第二條 合約期間與自動展延：
1. 本合約期間以十二（12）個月為一期，或依實際專案長度（若超過前述期間者，以較長者為準）。
2. 期滿時，如任一方未於期滿前三十（30）日至七（7）日間以書面（含電子郵件或其他足資使人知悉之方式）表達不續約，則視為自動續約一至二期（由甲方滾動評估）。
3. 若對是否續約或續約期數有爭議，以甲方之內部紀錄或對外之合理表示為準。
第三條 價金與付款條件：
1. 服務費用之計價基準原則上以甲方之驗收或里程碑之達成為主；具體金額、單價與計算方式由雙方另行議定或參照慣例（如月費、時數或件計），必要時得由甲方先行估列後再調整。
2. 乙方應於每月結算後開立發票；甲方得於發票收訖後三十（30）或九十（90）日內付款，惟若甲方內部流程尚在進行或遇有不可歸責事由，得順延至該流程完成或事由消失後之合理時點。
3. 甲方得就乙方任何應收款逕行抵銷甲方對乙方之任何現存、將來或或有債權，毋須事前通知；如乙方有異議，雙方得再協調。
4. 若發生多付或少付，雙方得於後續期別中調整，是否計息由雙方另議。
第四條 驗收與服務水準：
1. 乙方之交付物應由甲方進行形式或實質驗收。驗收標準原則上由甲方依實際情況合理認定；如無法明確判斷，得參酌一般業界慣行或先前版本表現。
2. 若甲方認為交付未達預期，乙方應於合理期限內（通常不逾一至數個版本迭代）免費重作或調整至甲方滿意為止；惟如甲方需求有重大變動，相關費用與進度得另議
3. 甲方得於驗收合格後三十（30）日內付款；惟對未盡義務部分，甲方得予以扣款或保留相當比例之保留款，金額由甲方依風險評估。
4. 乙方原則上對驗收標準不提出異議；若有必要，乙方得就重大或顯失公平部分提出說明。
5. 維運服務水準（SLA）以「重要服務不中斷」為目標；何謂「重要」與「不中斷」之定義，雙方得依實務調整並不定期記錄在內部文件或郵件往來。
第五條 智慧財產權：
1. 乙方保證其提供之服務及交付物原則上不侵害第三人權利；如有爭議，乙方將依合理範圍負責處理，甲方得視狀況協助。
2. 乙方於本服務期間產生之一切成果（包含但不限於文件、程式碼、設計、方法、改良、衍生著作等）之權利歸屬，除雙方另有明確書面約定外，原則上歸甲方或由甲方享有優先使用與再授權之權利；但乙方得保留其一般性或通用性部分之非獨占權利以供重複使用。
3. 對於乙方既有技術之改良或衍生成果，如與甲方需求密切相關者，乙方同意就其合理範圍內提供甲方無償、不可撤回但在合理期間內之使用許可；何謂「合理期間」由雙方斟酌個案認定。
4. 甲方對成果之標示、再利用與揭露原則上不受限制；惟如涉及乙方應受保護之商業秘密，雙方得以善意協商方式處理。
第六條 保密與資料：
1. 除法律另有規定外，甲方與乙方就對方資料（含個資、商業資訊等）均應以不低於一般業界通行水準予以保護；實際措施視成本效益與急迫性而定。
2. 如發生資安事件或疑似外洩，乙方應於知悉後儘速（通常為二十四〔24〕小時內）通知甲方並配合處理；相關損害與費用之分擔，雙方可先行因應，事後結算。
3. 甲方得於必要時要求乙方提供稽核或掃描報告；乙方原則上配合，惟若涉及重大機密或第三方權利者，得以等效資訊替代。
第七條 責任與保證：
1. 乙方就本服務提供一般性之品質保證，力求無錯誤、不中斷且符合甲方主要使用情境；如遇不可抗力、第三方因素或甲方環境限制，乙方之義務得相應調整。
2. 對於因本服務所生之損害，乙方應就可歸責部分負責；損害類型之認定以雙方合理預見為限。若法律另有強制規定，從其規定。
3. 本合約下乙方之總賠償責任，以最近一期（或最近十二個月）乙方就本服務實際收受之對價總額為上限；但如屬重大過失或故意，或本合約另有規定者，不在此限。若本條與前述任何無上限之表述牴觸，從較能兼顧風險之解釋。
4. 若第三人對甲方提出主張或訴訟，乙方將在合理範圍內協助並與甲方協同處理；必要時就可歸責於乙方部分提供補償。具體程序與費用分擔，依事件性質另行議定或準用第十一條。
### 請審查此合約的內容文字表達以及風險控制。
""";
// 執行 Sequential Orchestration
var result = await orchestration.InvokeAsync(input, runtime);
string finalReport = await result.GetValueAsync(TimeSpan.FromSeconds(3000));
Console.WriteLine("\n審查完成：");
Console.WriteLine(finalReport);
await runtime.RunUntilIdleAsync(); // 確保所有背景工作完成
審查完成：
## 文字內容審查意見
- 片段：「乙方原則上提供「系統」及相關之建置、維運、顧問等服務（以下合稱「本服務」）；「系統」之範圍包含但不限於流程、平台、工具及其他視情況需要之組件，實際內容以雙方後續往來之任何文字、口頭或默示同意為準。」
建議：此處「口頭或默示同意」容易產生爭議，建議將「口頭或默示同意」明確排除，改為「須有書面確認（包括電子郵件）」才能構成系統範圍的變更，避免日後認定分歧。
- 片段：「何謂『合理』，由甲方依個案衡量。」
建議：「合理」若完全由甲方單方決定，不利乙方。建議增加「經雙方協商」或「依雙方書面協議」為准，以保障乙方權益。
- 片段：「委由適當第三人處理（是否需告知甲方，依案件緊急程度而定）。」
建議：「依案件緊急程度而定」不明確，建議定義「緊急」狀態，或規定除非特殊緊急狀況，原則上均須告知甲方。
- 片段：「技術規格與細節原則上以甲方內部文件或慣例為準；如未能及時提供，乙方得以通行作法或其專業判斷先行辦理，事後再行確認。」
建議：乙方先行辦理後如甲方事後不同意，將產生爭議。建議於「事後再行確認」中補充「雙方就調整所需時間及費用協議辦理」，以保護乙方。
- 片段：「如雙方對前述定義有理解歧異，優先依本條第2款及附件A（如有）之規定處理；附件A未附時，由甲方之記錄或郵件摘要供參考。」
建議：甲方之記錄或郵件摘要單方產生，建議明確「由雙方確認之記錄」為準。
- 片段：合約自動續約機制，「由甲方滾動評估。」
建議：「由甲方滾動評估」定義不清，易生歧見。建議明確乙方有知悉評估結果之權利、評估條件及通知流程。
- 片段：「如乙方有異議，雙方得再協調。」
建議：協調無結論時是否可以尋求調解、中立第三方協助等，建議補充流程。
- 片段：「驗收標準原則上由甲方依實際情況合理認定」、「乙方原則上對驗收標準不提出異議；若有必要，乙方得就重大或顯失公平部分提出說明。」
建議：驗收標準建議事先以書面明訂或至少附件A明載，否則由「甲方合理認定」且乙方原則上不得異議，對乙方極為不利。
- 片段：「重要服務不中斷」為目標；何謂「重要」與「不中斷」之定義，雙方得依實務調整並不定期記錄在內部文件或郵件往來。
建議：此為關鍵服務內容，但定義模糊。建議在合約內直接明載「重要服務」範圍，以及計算「不中斷」指標、不可用排除條件等，減少糾紛。
- 片段：「乙方於本服務期間產生之一切成果…之權利歸屬，除雙方另有明確書面約定外，原則上歸甲方或由甲方享有優先使用與再授權之權利；但乙方得保留其一般性或通用性部分之非獨占權利以供重複使用。」
建議：「一般性或通用性部分」認定標準建議明訂，否則易有爭議。
- 片段：「甲方對成果之標示、再利用與揭露原則上不受限制；惟如涉及乙方應受保護之商業秘密，雙方得以善意協商方式處理。」
建議：「善意協商」無實質約束，建議增列保密範圍、除外情形，以及爭議解決機制。
- 片段：「甲方得於必要時要求乙方提供稽核或掃描報告；乙方原則上配合，惟若涉及重大機密或第三方權利者，得以等效資訊替代。」
建議：「等效資訊」應明確約定定義及提供形式，以免甲方不認可。
- 片段：「本合約下乙方之總賠償責任，以最近一期（或最近十二個月）乙方就本服務實際收受之對價總額為上限；但如屬重大過失或故意，或本合約另有規定者，不在此限。」
建議：何謂「重大過失」建議補充定義，另「本合約另有規定」若未明確說明，易產生責任無上限之疑慮。
- 片段：「若本條與前述任何無上限之表述牴觸，從較能兼顧風險之解釋。」
建議：「較能兼顧風險」用語過於籠統，建議刪除或明定以有上限規定優先。
- 片段：「具體程序與費用分擔，依事件性質另行議定或準用第十一條。」
建議：「第十一條」未附，應確認第十一條內容並補上。
【綜合建議】
此合約目前大部分用語偏重甲方解釋權，乙方（即貴司）立場與風險控制空間小，建議就上述疑義條文重議、補充明確用詞（例如「合理」標準必須雙方確認、成果歸屬明訂新舊技術界線、付款條件不宜由甲方內部流程無限制順延等）。
若貴司議價能力有限，至少要求所有因「書面/雙方書面確認」始生效力，口頭/默示同意原則上不生效，且各種關鍵定義、例外、賠償條款（尤其「合理」或「一般性」等認定）事前明確白紙黑字協議，切勿僅以「甲方認定」模糊約定。
如采上述建議修正，可大幅減少後續爭議及責任風險。
## 合約不平等風險審查意見
- 片段：「何謂『合理』，由甲方依個案衡量。」
風險：出現單方面解釋權，乙方弱勢，易造成重大爭議，在履約或責任分配時不利乙方。
建議：應改為「合理」標準由雙方書面確認，或引入第三方參考標準，若存爭議可採公正第三方仲裁決定。
- 片段：「實際內容以雙方後續往來之任何文字、口頭或默示同意為準。」
風險：允許口頭或默示同意，客觀證明困難，將使權利義務範圍不明，易引發訴訟及爭議。
建議：改為僅以「雙方書面（含電子郵件）確認」方為合約效力基礎。
- 片段：「驗收標準原則上由甲方依實際情況合理認定」、「乙方原則上對驗收標準不提出異議。」
風險：驗收標準由甲方單方決定，且乙方不得異議，責任風險全部轉嫁乙方，內容明顯不平等。
建議：事先明定驗收標準並以書面作成，否則應保留乙方對驗收有合理異議及申訴權利。
- 片段：「本合約下乙方之總賠償責任…為上限；但如屬重大過失或故意，或本合約另有規定者，不在此限。」
風險：「重大過失」無明確定義，「合約另有規定」未指明，賠償規範不明時等於乙方法律責任無限延伸，責任限制形同虛設。
建議：盡量明文化約中所有例外條款定義與適用範疇。可引入例如「僅對人身傷害、重大故意侵權例外」原則。
- 片段：「甲方對成果之標示、再利用與揭露原則上不受限制；惟如涉及乙方應受保護之商業秘密，雙方得以善意協商方式處理。」
風險：「善意協商」未具體化且無保證，恐令乙方商業秘密保護流於空談。
建議：明確增設保密義務、保密範圍、除外狀況、違約責任及緊急救濟措施。
- 片段：「甲方得於必要時要求乙方提供稽核或掃描報告；乙方原則上配合，…以等效資訊替代。」
風險：「等效資訊」無定義，甲方可否認乙方所提資訊是否等效具有高度任意性。
建議：建議「等效資訊」定義具體且應以雙方書面同意為準。
- 片段：「甲方之記錄或郵件摘要供參考。」
風險：甲方單方記錄缺乏證據力與中立性。
建議：以雙方共同確認紀錄為認定基礎。
- 片段：「若本條與前述任何無上限之表述牴觸，從較能兼顧風險之解釋。」
風險：「較能兼顧風險」用語籠統，留下條文落差解釋空間，等同重要責任條件由解釋決定，危及乙方利益。
建議：責任金額上限相關條文應明文化，避免不同條文互相牴觸。
【總結】
本案合約中，甲方保有多項單邊解釋權、驗收等裁量權及成果/損害賠償規定疑點顯著，主要法律風險來自條款過度偏向委託方，乙方容易無法有效主張權利與限制自身風險，建議乙方依前述具體建議爭取調整，優化責任分攤安排。
## 修正後合約內容（最終報告）
本修正依據上述審查意見，細則如下：
1. 服務內容及系統範圍
乙方原則上提供「系統」及相關之建置、維運、顧問等服務（以下合稱「本服務」）；「系統」之範圍包含但不限於流程、平台、工具及其他視情況需要之組件。任何系統範圍或服務內容之變更，須以雙方書面確認，包括但不限於正式郵件或合約補充條文方為有效。口頭或默示同意不得構成對本合約之任何變更或補充。
2. 合約解釋與合理性判斷
凡合約所涉「合理」、「適當」、「必要」等條件，均須由雙方協商並以書面確認。若雙方對合理性存有爭議時，得請第三方公正專業機構協助判定。
3. 技術規格與細節
技術規格與細節以雙方書面確認文件或明確附件為準。如甲方未能於合理期間內提供，乙方得以其專業判斷及產業通行作法先行辦理，並以書面形式通知甲方後，再依甲方書面意見進行必要調整。雙方應同步協議因調整所需之合理時間與費用。
4. 第三人委託
乙方如須委由第三人處理相關業務，應原則上提前書面告知甲方。惟因不可預見且涉及緊急危害服務持續性之情形，乙方得於事後最短時間內補行書面告知。
5. 定義歧異與文件認定
如雙方對定義或履約內容有歧異，優先依本條及附件A（如有）之書面協議或紀錄處理；附件A未附時，以雙方書面確認之紀錄或郵件摘要為準，單方所立紀錄不得作為唯一依據。
6. 自動續約及評估
合約有自動續約機制時，由甲方於評估時須提前X日書面告知乙方評估內容及結果，乙方有權查詢評估依據並提出異議，雙方原則上協議處理，如協議不成，得尋求調解。
7. 驗收標準
驗收標準原則上需於附件A中明列並由雙方書面確認。甲方如認有必要臨時調整驗收標準，應以書面通知乙方，乙方有合理申訴及協商權利。協議不成時，可尋求第三方公正專家協定。乙方就重大或顯失公平部分得提出書面說明並請求協商。
8. 重要服務不中斷
「重要服務」範圍及「不中斷」定義，應於本合約中明確列明或於附件中界定，包括績效指標、不可抗力/例外條件之排除，並以雙方每季/半年會議及書面記錄調整為依據。
9. 成果權利歸屬
乙方於本服務期間產生之一切成果，除雙方另有明確書面約定外，專屬權利及優先使用權歸甲方。惟乙方得保留事前書面列明且定義之「一般性或通用性部分」之非獨占性重複使用權，該部分應附於本合約附件B中詳列。
10. 成果標示與保密
甲方對成果標示、再利用、揭露等原則上不限。惟如涉及乙方應受保護之商業秘密及專有技術信息，雙方應事前以書面清單作成明確範圍，並就保密義務、除外事由、違約責任、緊急救濟流程予以明確規定。
11. 稽核、掃描及資訊提供
甲方得於必要時要求乙方配合資訊稽核、安控掃描等報告。乙方如因涉及重大機密或第三方權利，得以經雙方書面同意之等效資訊替代，所稱「等效資訊」之定義及提供方式亦須事先書面訂明。
12. 責任限制及例外
乙方於本合約下因可歸責於自身之事由所生之賠償責任，以最近一期（或最近十二個月）乙方就本服務實際收受對價總額為上限。惟如涉及乙方故意侵權或依中華民國法令不得預先免責範圍時，不適用本責任上限。所稱「重大過失」定義，應明列於本合約專章且限於違反保密義務、人身傷害或重大安全故障等。
13. 條文衝突之解釋
若本條與前開條文有關責任範圍、賠償限制等牴觸時，概以載明上限者優先適用。若有疑義應以不致造成乙方無上限責任為原則。
14. 費用及程序之分擔
合作中需追加費用、程序爭議者，依據事件性質雙方書面協議決定，原則上參照本合約第十一條（附件需補齊/明確該條內容），如無法協議則得訴諸調解或仲裁機制。
【附註】保留所有既有意見，未刪除。以上修正建議所產生條文，請搭配現行合約並納入附件或補充協議合併閱覽，確保雙方法定、契約上權利義務均有實質文字保障。
經過二個範例的詳細說明與實作，應該可以理解如何利用 SequentialOrchestration 編排系統來協調多個專責代理人 (ChatCompletionAgent)，達成順序式複雜任務的分工與合作。在這個合約審查的場景中，每個代理人專注於不同的審查階段，確保每個環節都能得到充分的關注和處理。
明天將探討另一種不一樣的多代理協作模式。請繼續關注！
iThome鐵人賽
看影片追技術