Trong vài năm qua, cách chúng ta xây chatbot và agent trong Microsoft Copilot Studio đã thay đổi khá nhiều.

Ban đầu, tư duy khá đơn giản:

User
  ↓
Question
  ↓
Topic
  ↓
Condition
  ↓
Action
  ↓
Response

Cách tiếp cận này hoạt động rất tốt khi bài toán đã được xác định rõ.

Ví dụ:

“Nhân viên hỏi số ngày phép còn lại.”

Agent nhận câu hỏi → tìm dữ liệu → trả lời.

Nhưng điều gì xảy ra khi yêu cầu trở thành:

“Kiểm tra hóa đơn này, tìm Purchase Order tương ứng, so sánh số lượng và giá trị, kiểm tra policy của công ty, nếu có sai lệch thì tạo approval request và thông báo cho Finance.”

Lúc này, chúng ta không còn xử lý một câu hỏi đơn lẻ.

Agent phải:

• Hiểu mục tiêu;
• Tìm dữ liệu;
• Lựa chọn công cụ;
• Thực hiện nhiều bước;
• Phân tích kết quả trung gian;
• Quyết định bước tiếp theo;
• Xử lý trường hợp lỗi;
• Và cuối cùng hoàn thành business process.

Đây chính là nhóm bài toán mà GitHub Copilot harness trong Microsoft Copilot Studio được thiết kế để giải quyết.

1. GitHub Copilot Harness là gì?

Một trong những điều dễ gây hiểu nhầm nhất nằm ngay trong cái tên.

GitHub Copilot harness không có nghĩa là đưa GitHub Copilot vào bên trong Copilot Studio.

Trong Microsoft Copilot Studio, harness là runtime đứng giữa agent/workflow và model. Nó quyết định khi nào gọi model, context nào được đưa vào model, xử lý kết quả ra sao và khi nào cần gọi tool.

Có thể hình dung:

                         AGENT
                           │
             Instructions / Knowledge / Tools
                           │
                           ▼
                  ┌─────────────────┐
                  │     HARNESS     │
                  │                 │
                  │    Runtime      │
                  │ Orchestration   │
                  │ Context         │
                  │ Tool execution  │
                  └────────┬────────┘
                           │
                           ▼
                         MODEL

Nói cách khác:

Model cung cấp reasoning và generation. Harness cung cấp runtime để agent sử dụng reasoning đó trong một hệ thống thực tế.

Microsoft hiện cung cấp nhiều harness trong Copilot Studio, trong đó GitHub Copilot harness tập trung vào các agent và workflow cần xử lý reasoning-heavy, multi-step business processes.

2. Tại sao cần một Harness mới?

Hãy lấy một ví dụ gần với các bài toán doanh nghiệp.

Giả sử chúng ta xây một IT Procurement Agent.

Nhân viên nói:

“Tôi cần một laptop cho developer mới sẽ gia nhập công ty vào thứ Hai tuần sau.”

Đây không phải một câu hỏi có một câu trả lời duy nhất.

Agent có thể cần phải:

1. Xác định nhân viên nào sẽ gia nhập
2. Kiểm tra policy về thiết bị
3. Xác định loại laptop phù hợp
4. Kiểm tra inventory
5. Kiểm tra ngân sách
6. Tạo hardware request
7. Gửi approval
8. Thông báo cho IT

Điều thú vị là agent không nhất thiết biết trước toàn bộ đường đi.

Ví dụ:

Inventory
   ↓
No suitable laptop
   ↓
Check procurement policy
   ↓
New purchase required
   ↓
Check budget
   ↓
Budget unavailable
   ↓
Ask manager for approval

Đây là một workflow có tính adaptive.

Microsoft mô tả GitHub Copilot harness là harness phù hợp với các scenario mà agent cần nhận một goal, chia nhỏ thành các bước, gọi tools/knowledge/MCP/connected agents và điều chỉnh khi một bước thất bại hoặc request thay đổi.

3. Standard Harness và GitHub Copilot Harness

Đây là điểm cần hiểu trước khi bắt đầu xây agent.

Copilot Studio hiện cho phép agent chạy trên các harness khác nhau, và việc lựa chọn harness ảnh hưởng trực tiếp đến cách agent hoạt động cũng như capability và billing.

Có thể tóm tắt:

Microsoft cũng nhấn mạnh rằng standard harness vẫn được hỗ trợ. Không phải GitHub Copilot harness xuất hiện thì mọi agent đều phải chuyển sang nó.

Vì vậy, câu hỏi không phải:

“Harness nào mới hơn?”

Mà là:

“Bài toán của tôi cần loại runtime nào?”

4. Từ Conversation Flow đến Goal

Đây có lẽ là thay đổi quan trọng nhất.

Với cách tiếp cận truyền thống, developer thường bắt đầu bằng việc thiết kế flow.

Ví dụ:

User asks for laptop
        │
        ▼
Get employee
        │
        ▼
Check inventory
        │
        ▼
Is laptop available?
      /       \
    Yes        No
    /           \
Create       Procurement
request       request

Chúng ta đang trả lời câu hỏi:

“Conversation này sẽ đi theo đường nào?”

Với GitHub Copilot harness, tư duy chuyển thành:

                    GOAL
                     │
                     ▼
             "Get a laptop for
              a new developer"
                     │
                     ▼
              ORCHESTRATION
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Knowledge    Tools      Skills
          │          │          │
          └──────────┼──────────┘
                     ▼
                  Result
                     │
                     ▼
              What happens next?
                     │
              ┌──────┴──────┐
              ▼             ▼
          Continue         Done

Thay vì phải mô tả trước từng branch, chúng ta tập trung mô tả:

• agent là ai;
• agent cần làm gì;
• agent biết gì;
• agent được phép làm gì;
• agent không được làm gì;
• những capability nào agent có thể sử dụng.

Đây là natural-language-first approach mà Microsoft đưa vào GitHub Copilot harness.

5. Một Agent trong GitHub Copilot Harness gồm những gì?

Trong experience mới, Microsoft gom các thành phần chính của agent vào Build tab:

                  AGENT
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
 Instructions   Knowledge      Model
       │
       ├──────── Tools
       │
       ├──────── Skills
       │
       ├──────── Connected Agents
       │
       └──────── Memory

Microsoft hiện tổ chức Build experience xung quanh identity, knowledge, tools, skills, model và memory.

Đây là nơi tôi nghĩ nên chèn screenshot Copilot Studio trong bài.

[Hình 1 – Screenshot Build tab của một agent chạy trên GitHub Copilot harness]

Bạn có thể highlight:

• Instructions
• Knowledge
• Tools
• Skills
• Connected Agents
• Memory

Hình này sẽ giúp người đọc hiểu ngay rằng GitHub Copilot harness không chỉ là một “chat UI” mới.

6. Instructions: Thay vì vẽ mọi nhánh, hãy mô tả Agent

Ví dụ chúng ta tạo một IT Procurement Agent.

Instructions có thể bắt đầu như:

You are an IT procurement agent.

Your responsibilities are:
- Help employees request hardware.
- Check company procurement policies.
- Check available inventory.
- Create hardware requests when appropriate.

You must:
- Verify the employee before creating a request.
- Never approve your own request.
- Ask for missing information.
- Check inventory before recommending a device.

Điểm quan trọng ở đây là chúng ta đang mô tả behavior và boundaries của agent thay vì xây toàn bộ conversation tree.

Microsoft mô tả GitHub Copilot harness theo hướng natural-language-first: instructions được dùng cùng knowledge và tools để enhanced orchestration xác định khi nào cần sử dụng từng capability.

7. Knowledge: Agent không thể reasoning trên thứ nó không biết

Instructions chỉ nói agent nên làm gì.

Knowledge cung cấp thông tin để agent biết về cái gì.

Ví dụ IT Procurement Agent có:

                    IT AGENT
                       │
                 ┌─────┴─────┐
                 ▼           ▼
           Instructions    Knowledge
                              │
                    ┌─────────┼─────────┐
                    ▼         ▼         ▼
                 IT Policy  Hardware   Security
                            Catalog     Policy

Ví dụ user hỏi:

“Tôi có thể mua MacBook Pro cho intern không?”

Agent cần:

1. biết employee thuộc nhóm nào;
2. biết policy;
3. biết device catalog;
4. có thể cần kiểm tra inventory.

Knowledge và tools lúc này đóng vai trò khác nhau.

Knowledge trả lời:

“Company policy nói gì?”

Tool trả lời:

“Hệ thống hiện tại có dữ liệu gì?”

Đây là distinction rất quan trọng khi thiết kế agent.

8. Tools: Agent bắt đầu có khả năng hành động

Knowledge giúp agent biết.

Tool giúp agent làm.

Ví dụ:

Create Hardware Request
Check Inventory
Get Employee
Check Budget
Create Approval
Send Notification

Kiến trúc bắt đầu trở thành:

                   AGENT
                     │
                ORCHESTRATOR
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Knowledge    Tool       Skill
                     │
              ┌──────┼──────┐
              ▼      ▼      ▼
             API   MCP   Workflow

Microsoft hiện cho phép GitHub Copilot harness sử dụng custom tools, trong đó có MCP tools và workflows. Đáng chú ý, Microsoft yêu cầu tool có name và description rõ ràng vì orchestration runtime sử dụng thông tin này để quyết định khi nào invoke tool.

Điều này dẫn tới một nguyên tắc khá thú vị:

Tool description không còn chỉ là documentation cho developer. Nó trở thành một phần input cho orchestration.

Ví dụ:

Không tốt:

Ticket Tool

Tốt hơn:

Create support ticket

Use this tool when the user needs to create
a new IT support ticket.

Returns the ticket ID and current status.

Microsoft cũng khuyến nghị tránh những tool có description quá mơ hồ hoặc chồng chéo nhau.

[Hình 2 – Screenshot cấu hình Tool + phần Description]

Đây là một screenshot rất đáng cài vào bài vì nó minh họa được một concept chứ không chỉ trang trí.

9. MCP: Khi Tool không còn chỉ nằm trong Power Platform

Một điểm thú vị của GitHub Copilot harness là MCP.

Nếu hệ thống của bạn có một MCP server:

                    AGENT
                      │
                      ▼
                   MCP Tool
                      │
                      ▼
              ┌──────────────┐
              │ MCP Server   │
              └──────┬───────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          API      Database  Service

Agent có thể sử dụng những capability đó như tools.

Microsoft hiện cho phép thêm MCP tools từ một MCP server có sẵn vào agent chạy trên GitHub Copilot harness.

Đây là một thay đổi quan trọng về architecture.

Agent không nhất thiết phải biết implementation phía dưới.

Nó chỉ cần biết:

“Tôi có một capability có thể thực hiện việc X.”

10. Skills: Đóng gói một loại năng lực

Nếu tools là những capability đơn lẻ, skills cho phép đóng gói reusable capability cho agent.

Ví dụ:

Skills
│
├── customer-support-escalation
├── invoice-processing
├── employee-onboarding
└── procurement-review

Một skill có thể chứa:

• description;
• instructions;
• steps;
• response format;
• edge cases;
• references tới tools.

Microsoft hiện cho phép tạo custom skill trực tiếp từ Build tab và mô tả skill bằng Markdown instructions. Description của skill cũng được orchestration runtime sử dụng để xác định khi nào skill nên được kích hoạt.

Ví dụ:

Skill: invoice-processing

Description:
Process supplier invoices, compare them
with purchase orders, and identify exceptions.

Instructions:
1. Identify the invoice.
2. Find the matching purchase order.
3. Compare quantities and amounts.
4. Identify discrepancies.
5. Route exceptions for approval.

Tư duy lúc này trở thành:

Tool
  ↓
Một capability

Skill
  ↓
Một reusable way of solving a class of problems

11. Workflow: Agentic không có nghĩa là để AI làm tất cả

Đây là phần tôi đặc biệt khuyến nghị đưa vào bài.

Giả sử agent phát hiện invoice có discrepancy.

Agent không nên tự “đoán” cách tạo approval.

Thay vào đó:

Agent
  │
  │ Reasoning
  ▼
"An approval process is required"
  │
  ▼
Workflow
  │
  ├── Validate request
  ├── Create approval
  ├── Update record
  └── Notify Finance

Workflow vẫn là nơi phù hợp cho những logic cần deterministic execution.

Microsoft mô tả workflow là automation dành cho các process lặp lại, deterministic như approval, data transformation và business logic. Workflow có thể được thêm vào agent như một tool.

Một câu có thể dùng làm highlight trong bài:

Agent quyết định khi nào cần thực hiện một business process; workflow đảm bảo process đó được thực thi nhất quán.

Đây là cách kết hợp Agentic AI với automation thay vì cố biến mọi thứ thành LLM reasoning.

12. Một ví dụ hoàn chỉnh: Invoice Processing Agent

Bây giờ ghép tất cả lại.

Giả sử Finance upload:

Invoice_2026_0912.pdf

Agent nhận yêu cầu:

“Please process this invoice.”

Architecture:

                         USER
                           │
                           ▼
                    Invoice.pdf
                           │
                           ▼
              ┌─────────────────────┐
              │   Invoice Agent     │
              │                     │
              │ GitHub Copilot      │
              │ Harness             │
              └──────────┬──────────┘
                         │
                   Orchestration
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
    Knowledge          Tools            Skills
        │                │                │
        │         ┌──────┼──────┐         │
        │         ▼      ▼      ▼         │
        │       MCP     API   Workflow    │
        │                                  │
        └────────────────┬─────────────────┘
                         ▼
                   Intermediate
                     results
                         │
                         ▼
                    Final decision

Agent có thể thực hiện:

Step 1 — Read invoice

Invoice number
Supplier
Amount
Line items
PO number

Step 2 — Find Purchase Order

Tool gọi ERP hoặc MCP server.

Step 3 — Compare

Invoice amount = $12,500
PO amount      = $12,500

Result: MATCH

Hoặc:

Invoice amount = $14,500
PO amount      = $12,500

Difference = $2,000

Step 4 — Check policy

Agent sử dụng knowledge:

Differences above $1,000 require Finance Manager approval.

Step 5 — Execute workflow

Create approval request
        ↓
Update invoice status
        ↓
Notify Finance Manager

Đây là một scenario mà GitHub Copilot harness đặc biệt phù hợp: multi-step process, nhiều tools, intermediate decisions và khả năng làm việc với file. Microsoft cũng sử dụng accounts payable/invoice matching làm ví dụ cho harness này.

13. Agent không chỉ trả về Text

Một điểm khá thú vị của GitHub Copilot harness là file handling.

Microsoft hiện mô tả khả năng agent create, edit và reason over:

• Word
• Excel
• PowerPoint
• PDF

trên GitHub Copilot harness.

Ví dụ sau khi xử lý 100 invoice:

Invoices
   │
   ▼
Agent
   │
   ├── Analyze
   ├── Match
   ├── Detect exceptions
   │
   ▼
Excel Report
   │
   ├── Matched invoices
   ├── Exceptions
   └── Approval status

[Hình 3 – Agent tạo Excel report từ invoice processing scenario]

Đây là loại hình ảnh có giá trị hơn một screenshot UI đơn thuần vì nó giúp người đọc hình dung business outcome.

14. Connected Agents: Khi một Agent không thể biết tất cả

Khi hệ thống lớn hơn, chúng ta có thể chia responsibility:

                    Procurement Agent
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
         Finance Agent  IT Agent     HR Agent

Ví dụ:

“Onboard this new employee.”

Main agent có thể cần:

HR Agent
 → employee information

IT Agent
 → laptop/account/access

Finance Agent
 → cost center/budget

GitHub Copilot harness hỗ trợ connected agents, cho phép primary agent invoke những agent khác trong quá trình xử lý conversation/task.

Đây là bước chuyển từ:

One giant agent

sang:

Specialized agents working together.

15. Build → Test → Evaluate → Publish → Monitor

Một agent production không nên kết thúc ở:

“Chat thử thấy nó trả lời đúng.”

GitHub Copilot harness hiện có lifecycle rõ ràng:

Create
  ↓
Build
  ↓
Preview
  ↓
Evaluate
  ↓
Publish
  ↓
Monitor

Trong experience mới:

Build

Cấu hình:

• identity;
• instructions;
• knowledge;
• tools;
• skills;
• model;
• memory.

Preview

Test conversation trực tiếp.

Evaluate

Tạo và chạy test sets để đánh giá chất lượng.

Monitor

Theo dõi task, activity và những file agent đã truy cập.

[Hình 4 – Screenshot Preview/Evaluate/Monitor tabs]

Nếu viết bài kỹ thuật, tôi rất khuyên có screenshot này vì nó giúp bài chuyển từ “giới thiệu feature” sang “engineering lifecycle”.

16. Debug Agent bằng Activity Trace

Một trong những vấn đề lớn nhất khi làm agent là:

“Tại sao agent lại làm như vậy?”

Với workflow truyền thống, ta có thể nhìn từng node.

Nhưng agentic system có thể có nhiều quyết định runtime.

Vì vậy trace trở nên quan trọng.

Khi một workflow được gọi như tool, Microsoft cho phép xem activity trace để kiểm tra:

• tool nào được invoke;
• arguments nào được truyền;
• tool trả về gì.

Tư duy debugging lúc này không còn đơn giản:

Node A → Node B → Node C

mà gần hơn với:

Goal
 ↓
Agent decision
 ↓
Tool invocation
 ↓
Result
 ↓
Next decision
 ↓
Tool invocation
 ↓
Result
 ↓
Final answer

Đây là một thay đổi rất lớn khi chuyển từ automation sang agent engineering.

17. Một điểm cần lưu ý: Tool description trở thành một phần của design

Nếu orchestration sử dụng description để quyết định tool nào nên được invoke, thì việc đặt tên tool trở thành một phần của agent design.

Ví dụ có hai tool:

Get Customer
Get Customer Details

Nếu description của hai tool gần như giống nhau, agent có thể khó phân biệt.

Thay vào đó:

Get Customer

Use this tool when you need to locate
a customer by customer ID or email.

Returns the customer's basic identity
and account status.

và:

Get Customer Details

Use this tool when you already know the
customer and need billing, contract,
or subscription information.

Returns detailed account information.

Microsoft cũng đưa chính xác recommendation này trong documentation về custom tools.

Đây là một ví dụ nhỏ nhưng rất thực tế:

Agent engineering không chỉ là viết prompt hay. Nó còn là thiết kế metadata cho các capability mà agent có thể sử dụng.

18. Có nên chuyển toàn bộ Agent sang GitHub Copilot Harness?

Không.

Đây là điểm tôi nghĩ nên nói rõ trong bài.

Nếu bạn có:

“What is the company’s vacation policy?”

và agent chỉ cần:

Question
 ↓
Knowledge
 ↓
Answer

thì không nhất thiết phải dùng một runtime hướng tới complex multi-step work.

Ngược lại, nếu agent phải:

Understand goal
 ↓
Search multiple sources
 ↓
Call several tools
 ↓
Analyze results
 ↓
Create/update files
 ↓
Delegate to another agent
 ↓
Execute workflow
 ↓
Recover from problems

thì GitHub Copilot harness bắt đầu có nhiều giá trị hơn.

Microsoft cũng định vị lựa chọn này theo đúng hướng đó: GitHub Copilot harness cho complex, multi-step business processes; standard harness cho structured, predictable scenarios.

19. Một lưu ý rất quan trọng: Cost

GitHub Copilot harness sử dụng Copilot Credits theo usage-based billing.

Và không chỉ production usage.

Microsoft ghi rõ usage-based billing có thể áp dụng cho:

• using;
• building;
• testing;
• evaluating

agent hoặc workflow chạy trên GitHub Copilot harness.

Vì vậy khi xây agent, chúng ta không nên chỉ quan tâm:

Does it work?

mà nên quan tâm:

Does it work?
       +
Is it reliable?
       +
Is it secure?
       +
Is it observable?
       +
Is the cost reasonable?

Đây chính là lúc Agent Engineering bắt đầu khác với việc đơn thuần xây chatbot.

20. GitHub Copilot Harness thay đổi mindset như thế nào?

Có thể nhìn sự thay đổi này qua một bảng đơn giản:

Đây không có nghĩa cách cũ đã lỗi thời.

Nó chỉ có nghĩa:

Chúng ta đang có thêm một abstraction phù hợp với những bài toán mà conversation flow truyền thống khó giải quyết.

21. Nhìn toàn bộ architecture

Nếu ghép tất cả lại, ta có:

                         USER
                           │
                           ▼
                         GOAL
                           │
                           ▼
              ┌──────────────────────┐
              │ GitHub Copilot       │
              │ Harness              │
              │                      │
              │ Enhanced             │
              │ Orchestration        │
              └──────────┬───────────┘
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
       ▼                 ▼                 ▼
 Instructions         Knowledge          Model
       │
       ├──────── Tools
       │             │
       │       ┌─────┼─────┐
       │       ▼     ▼     ▼
       │      API   MCP  Workflow
       │
       ├──────── Skills
       │
       ├──────── Memory
       │
       └──────── Connected Agents
                         │
                         ▼
                  Business Systems
                         │
                         ▼
                       Result

Và lifecycle:

      BUILD
        │
        ▼
     PREVIEW
        │
        ▼
    EVALUATE
        │
        ▼
     PUBLISH
        │
        ▼
     MONITOR
        │
        └──────────► IMPROVE

Đây mới là cách tôi nghĩ nên nhìn GitHub Copilot harness.

Nó không đơn giản là một tính năng mới trong Copilot Studio.

Kết luận

Microsoft Copilot Studio đang dần chuyển từ tư duy:

“Build a chatbot that knows how to respond.”

sang:

“Build an agent that knows how to accomplish a goal.”

GitHub Copilot harness là một phần quan trọng của sự chuyển dịch đó.

Với standard approach, chúng ta thường bắt đầu bằng conversation:

User
 ↓
Topic
 ↓
Branch
 ↓
Action
 ↓
Response

Với GitHub Copilot harness, chúng ta bắt đầu từ business goal:

Goal
 ↓
Reason
 ↓
Choose capability
 ↓
Execute
 ↓
Observe
 ↓
Adapt
 ↓
Complete

Những capability như Knowledge, Tools, MCP, Skills, Workflows, Memory và Connected Agents không tồn tại độc lập. Chúng trở thành những building blocks mà enhanced orchestration có thể sử dụng để hoàn thành một task.

Và có lẽ đây mới là điều đáng chú ý nhất:

Agentic AI không đơn giản là cho LLM nhiều quyền hơn. Đó là việc xây dựng một runtime đủ tốt để LLM có thể reasoning, sử dụng capability, xử lý kết quả và hoàn thành business process trong những giới hạn mà chúng ta kiểm soát được.

Đó cũng là lý do GitHub Copilot harness đáng được nhìn nhận như một agent runtime mới trong Copilot Studio, thay vì chỉ là một UI authoring experience mới.