Harness Engineering: 쉽게 무너지지 않는 AI 에이전트 구축을 위한 완벽 가이드

대부분의 사람들은 AI 에이전트를 개선하려고 할 때 잘못된 계층에서 접근합니다.

에이전트가 실패하면 프롬프트를 다시 작성합니다.

또 실패하면 지침을 더 추가합니다.

시작하기 전에:

새로운 AI 알파, 에이전트 워크플로우, 단계별 가이드를 X에 올리기 전에 먼저 제 Substack에서 받아보세요: [https://substack.com/@lunarresearcher

그러고는 모델을 바꾸고, 도구를 더 추가하고, 컨텍스트 윈도우를 늘린 다음, 다음 실행이 다르게 작동하길 바랍니다.

하지만 많은 에이전트 실패는 추론 실패가 아닙니다.

그것은 환경 실패입니다.

에이전트가 어떤 파일이 중요한지 몰랐습니다.

올바른 도구를 잘못된 위치에서 사용했습니다.

이전 세션에서 내린 결정을 잊어버렸습니다.

확인 절차를 실행하지 않고 성공했다고 주장했습니다.

부분 실패 후에 동작을 반복했습니다.

승인이 필요한 작업을 수행할 권한이 있었습니다.

모델 자체가 문제가 아닌 경우가 많았습니다. 모델을 둘러싼 시스템이 불완전했던 것입니다.

그 시스템이 바로 하네스(Harness)입니다.

그리고 이를 설계하는 것은 그 자체로 하나의 엔지니어링 분야가 되어가고 있습니다.

하네스 엔지니어링(Harness Engineering)은 모델의 지능을 신뢰할 수 있는 작업으로 전환하는 환경을 구축하는 실무입니다.

프롬프트는 한 번의 시도를 바꿉니다.

하네스는 모든 시도를 바꿉니다.

이 가이드는 하네스를 구축하는 방법을 설명합니다.

1. 모델은 에이전트가 아니다

모델은 추론하고, 생성하고, 비교하고, 선택할 수 있습니다.

하지만 에이전트는 실제 환경과 상호작용해야 합니다.

에이전트는 다음을 수행해야 합니다:

• 작업 이해
• 관련 컨텍스트 찾기
• 도구 선택 및 사용
• 상태 유지
• 권한 존중
• 결과 검사
• 실패로부터 복구
• 작업 완료 증명

모델은 그 시스템 내부의 추론 엔진입니다.

하네스는 추론을 실제로 작동하게 만드는 모든 것입니다.

1사용자 요청
2     |
3     v
4+-----------------------------+
5|           하네스            |
6| 계약 | 컨텍스트 | 정책     |
7| 도구 | 상태   | 검사       |
8| 추적 | 복구                |
9+-----------------------------+
10     |
11     v
12    모델
13     |
14     v
15실제 환경

약한 하네스 안의 강력한 모델은 여전히 약한 에이전트입니다.

인상적인 개별 응답을 생성할 수는 있지만, 긴 작업, 변화하는 환경, 부분적 실패에 걸쳐 일관성 없이 행동할 것입니다.

하네스 엔지니어링의 목표는 모델의 불확실성을 제거하는 것이 아닙니다.

그 불확실성을 관찰, 검증, 복구할 수 있는 시스템 안에 가두는 것입니다.

2. 작업 계약부터 시작하라

대부분의 에이전트 작업은 모호한 의도로 시작됩니다:

온보딩 플로우를 개선해줘.

그 한 문장이 대화에는 충분할 수 있습니다.

하지만 자율적인 실행에는 충분하지 않습니다.

에이전트가 행동하기 전에, 하네스는 요청을 작업 계약으로 변환해야 합니다.

유용한 계약은 다섯 가지 질문에 답합니다:

1. 어떤 결과물이 존재해야 하는가?
2. 범위 안에는 무엇이 포함되는가?
3. 변경되어서는 안 되는 것은 무엇인가?
4. 완료를 증명하는 증거는 무엇인가?
5. 어떤 작업에 인간의 승인이 필요한가?

1목표: 온보딩 이탈률 감소
2
3범위:
4  - 회원가입 플로우
5  - 온보딩 분석
6
7제약 조건:
8  - 인증은 변경하지 않음
9  - 기존 모바일 동작 유지
10
11승인 기준:
12  - 테스트 통과
13  - 분석 이벤트 발생
14  - 데스크탑 및 모바일 스크린샷 포함
15
16승인 필요:
17  - 프로덕션 배포
18  - 데이터베이스 마이그레이션

이것은 에이전트의 질문을 다음과 같이 바꿉니다:

다음에 무엇을 해야 하지?

에서:

어떤 행동이 환경을 계약된 결과물로 움직이게 하는가?

계약 없이 에이전트는 그럴듯한 활동을 최적화합니다.

계약이 있으면 검증된 완료를 최적화할 수 있습니다.

3. 에이전트에게 매뉴얼이 아닌 지도를 제공하라

전체 저장소, 문서 세트, 대화 기록을 컨텍스트에 덤프하는 것은 좋은 컨텍스트 엔지니어링이 아닙니다.

그것은 컨텍스트 홍수입니다.

하네스는 먼저 작은 지도를 제공하고, 관련성이 생겼을 때 에이전트가 세부 정보를 검색하도록 해야 합니다.

1프로젝트 지도
2
3제품 규칙     -> docs/product/
4아키텍처      -> docs/architecture.md
5프론트엔드    -> apps/web/
6백엔드        -> services/api/
7테스트        -> tests/
8명령어        -> docs/commands.md
9릴리스 규칙   -> docs/release.md

이것이 점진적 공개(progressive disclosure)입니다:

1작업
2  -> 프로젝트 지도
3      -> 관련 하위 시스템
4          -> 정확한 파일
5              -> 로컬 지침

컨텍스트는 정보가 존재하기 때문에가 아니라 작업이 요구하기 때문에 확장되어야 합니다.

좋은 컨텍스트 컴파일러는 다음을 결정합니다:

• 항상 필요한 것
• 나중에 검색할 수 있는 것
• 오래된 것
• 요약할 수 있는 것
• 그대로 유지해야 하는 것

목표는 최대 컨텍스트가 아닙니다.

토큰당 최대 신호입니다.

4. 도구 더미가 아닌 도구 게이트웨이를 구축하라

에이전트에게 20개의 도구를 준다고 해서 능력이 생기는 것은 아닙니다.

에이전트에게 실수할 수 있는 20가지 방법을 주는 것뿐입니다.

모든 도구는 명확한 계약을 가져야 합니다:

1도구: edit_file
2
3입력:
4  path
5  patch
6
7사전 조건:
8  path 존재함
9  path가 허용된 작업 공간 내에 있음
10
11성공 증거:
12  패치 적용됨
13  결과 diff 반환됨
14
15실패 동작:
16  부분 덮어쓰기 없음
17  구조화된 오류 반환됨
18
19위험 등급:
20  되돌릴 수 있음

하네스는 도구가 어떻게 노출되고 사용되는지 제어해야 합니다.

다음을 수행할 수 있습니다:

• 관련 없는 도구 숨기기
• 인수 검증
• 경로 및 도메인 제한
• 타임아웃 설정
• 재시도를 멱등적으로 만들기
• 출력 정규화
• 위험한 작업에 확인 요구
• 단순히 "성공"이 아닌 증거 반환

이것은 중요한 분리를 만듭니다:

1모델이 의도를 결정
2게이트웨이가 동작을 검증
3도구가 환경을 변경
4센서가 결과를 관찰

모델은 동작을 제안할 수 있습니다.

도구 게이트웨이는 그 동작이 실행하기에 충분히 유효한지 결정합니다.

5. 두뇌, 손, 그리고 기록을 분리하라

많은 취약한 에이전트는 모든 것을 하나의 커져가는 기록에 섞어 넣습니다.

추론, 도구 호출, 파일, 결정, 오류, 오래된 관찰이 모두 동일한 컨텍스트 윈도우를 위해 경쟁합니다.

더 강력한 시스템은 세 가지 책임을 분리합니다:

1두뇌 (BRAIN)
2계획하고, 추론하고, 선택합니다
3
4손 (HANDS)
5통제된 환경 내에서 도구를 실행합니다
6
7기록 (HISTORY)
8지속적인 사실, 결정, 실행 상태를 저장합니다

모델이 활성 컨텍스트에 모든 원시 이벤트를 필요로 하는 것은 아닙니다.

올바른 현재 상태가 필요합니다.

샌드박스가 전체 목표를 이해할 필요는 없습니다.

제한된 동작을 안전하게 실행하기만 하면 됩니다.

세션 로그가 추론할 필요는 없습니다.

현재 컨텍스트가 사라진 후에 무슨 일이 일어났는지 보존하기만 하면 됩니다.

이러한 분리는 장기 실행 에이전트를 재개, 검사, 수정하기 쉽게 만듭니다.

또한 전체 시스템을 재구축하지 않고도 한 부분을 교체할 수 있게 해줍니다.

6. 메모리는 지속적인 상태가 되어야 한다

대화 기록은 신뢰할 수 있는 메모리가 아닙니다.

이벤트 스트림일 뿐입니다.

유용한 메모리는 명시적인 상태로 변환되어야 합니다.

최소한 네 가지 범주를 보존하십시오:

1사실 (FACTS)
2환경에 대해 발견된 안정적인 정보
3
4결정 (DECISIONS)
5내려진 선택과 그 이유
6
7진행 상황 (PROGRESS)
8완료된 작업, 활성 작업, 차단된 작업, 남은 작업
9
10교훈 (LESSONS)
11향후 행동을 변경해야 하는 실패

예를 들어:

1facts:
2  - 결제 검증 로직은 services/orders에 있음
3
4decisions:
5  - 기존 검증 파이프라인 재사용
6  - 이유: 두 번째 진실 공급원 방지
7
8progress:
9  completed:
10    - 서버 측 규칙 추가
11  remaining:
12    - 통합 테스트 업데이트
13
14lessons:
15  - 로컬 테스트 명령어는 TEST_DB_URL 필요

이것은 50페이지 분량의 기록을 재생하면서 모델이 중요한 줄을 알아차리길 바라는 것보다 훨씬 유용합니다.

감사 가능성을 위해 원시 기록을 저장하십시오.

실행을 위해 지속적인 상태를 컴파일하십시오.

7. 완료에는 증거가 필요하다

에이전트가 "다 했어"라고 말하는 것이 작업이 완료되었다는 증거는 아닙니다.

그것은 또 다른 모델 출력일 뿐입니다.

완료는 환경의 관찰 가능한 변화에 의해 결정되어야 합니다.

1주장                           증거
2--------------------------------------------------
3"버그가 수정되었습니다"        실패하던 테스트가 이제 통과함
4"페이지가 작동합니다"          브라우저 플로우 완료됨
5"마이그레이션은 안전합니다"    드라이 런과 롤백이 통과함
6"보고서가 정확합니다"          값이 원본 데이터와 일치함
7"작업이 완료되었습니다"        모든 승인 검사 통과함

하네스는 가장 저렴한 결정론적 검사를 먼저 실행해야 합니다.

1구문
2  -> 타입
3      -> 집중 테스트
4          -> 통합 테스트
5              -> 시각적 또는 의미론적 검토
6                  -> 인간 승인

컴파일러, 스키마, 체크섬, 쿼리 또는 테스트가 질문에 답할 수 있는 곳에 다른 모델을 사용하지 마십시오.

모호함에는 모델을 사용하십시오.

배관 작업에는 코드를 사용하십시오.

모델은 작업이 완료되었다고 제안할 수 있습니다.

오직 환경만이 그것을 증명할 수 있습니다.

8. 검증은 결과를 공격해야 한다

작업자와 평가자는 동일한 목표를 공유해서는 안 됩니다.

작업자는 가장 강력한 해결책을 만들려고 합니다.

평가자는 그것이 거부되어야 할 이유를 찾으려고 합니다.

1작업자
2  -> 후보 생성
3
4검증자
5  -> 계약 확인
6  -> 누락된 사례 검색
7  -> 뒷받침되지 않는 주장 테스트
8  -> 결과물을 깨뜨리려 시도
9
10생존 시
11  -> 수락
12
13실패 시
14  -> 대상 증거 반환

이 비대칭성은 중요합니다.

동일한 에이전트에게 동일한 컨텍스트에서 "자신의 작업을 다시 확인하라"고 요청하면, 실수를 만든 가정을 종종 유지합니다.

유용한 검증 단계는 다음을 가져야 합니다:

• 명시적인 거부 기준
• 생성된 아티팩트에 대한 접근
• 승인 계약에 대한 접근
• 필요할 때 독립적인 도구 또는 새로운 컨텍스트
• 수리 없이 거부할 수 있는 권한

검증은 두 번째 의견이 아닙니다.

반증 시도입니다.

9. 모델이 제안하고, 정책이 승인한다

일부 규칙은 모델이 그것을 기억하는지 여부에 절대 의존해서는 안 됩니다.

1승인 없이 절대 게시하지 않음
2비밀을 절대 노출하지 않음
3작업 공간 밖에 절대 쓰지 않음
4지출 한도를 절대 초과하지 않음
5실행하지 않고 테스트 통과로 표시하지 않음

이것들은 프롬프트 제안이 아닙니다.

정책입니다.

가장 안전한 설계는 정책을 추론 루프 밖에 두는 것입니다.

1낮은 위험
2파일 읽기, 검색, 검사
3-> 자동
4
5되돌릴 수 있는 변경
6작업 공간 편집, 테스트 실행
7-> 추적과 함께 자동
8
9외부 영향
10메시지 보내기, 배포, 구매
11-> 명시적 승인
12
13되돌릴 수 없거나 민감한 작업
14데이터 삭제, 자격 증명 순환, 전 세계 게시
15-> 강력한 차단 또는 금지

결과가 강력할수록 게이트도 더 강력해집니다.

자율성은 통제의 부재가 아닙니다.

명확하게 강제된 경계 내에서 자유롭게 운영할 수 있는 능력입니다.

10. 복구는 실패 클래스를 대상으로 해야 한다

가장 흔한 복구 전략은 다음과 같습니다:

뭔가 실패했어. 다시 시도해.

그것은 복구가 아닙니다.

반복입니다.

하네스는 다음 동작을 선택하기 전에 실패를 분류해야 합니다.

1도구 타임아웃
2-> 백오프와 함께 재시도
3
4잘못된 인수
5-> 도구 호출 수정
6
7컨텍스트 부족
8-> 특정 소스 검색
9
10테스트 실패
11-> 실패 동작 검사
12
13권한 거부
14-> 승인 요청 또는 안전한 경로 선택
15
16모순된 요구사항
17-> 인간에게 에스컬레이션
18
19변경 없이 반복된 실패
20-> 루프 중지

재시도는 적어도 하나의 관련 조건을 변경해야 합니다.

그렇지 않으면 시스템은 동일한 실패를 재현하기 위해 비용을 지불하는 것입니다.

제한된 에이전트 루프는 다음과 같습니다:

1관찰
2  -> 결정
3      -> 행동
4          -> 측정
5              -> 수락
6              -> 수리
7              -> 에스컬레이션
8              -> 중지

모든 루프에는 예산이 필요합니다:

• 최대 시도 횟수
• 최대 시간
• 최대 지출
• 최대 파괴 범위
• 에스컬레이션 조건

신뢰할 수 있는 에이전트는 계속하는 방법을 압니다.

또한 계속하는 것이 더 이상 합리적이지 않을 때를 압니다.

11. 지침은 인프라가 되어야 한다

에이전트 지침은 지역적 현실을 설명할 때 유용합니다.

하지만 지침만으로는 강제력이 약합니다.

규칙이 반복적으로 중요하다면, 스택 아래로 이동시키십시오.

1"포매터를 사용하세요"
2-> 포매터를 자동으로 실행
3
4"계층 간에 임포트하지 마세요"
5-> 아키텍처 테스트 추가
6
7"마이그레이션 롤백을 포함하세요"
8-> CI에서 롤백 파일 요구
9
10"생성된 파일을 수정하지 마세요"
11-> 생성된 경로에 쓰기 차단
12
13"모든 외부 주장을 인용하세요"
14-> 인용 범위 검증

이것은 지침 사다리를 만듭니다:

1설명
2  -> 체크리스트
3      -> 템플릿
4          -> 자동화된 검사
5              -> 강제된 정책

실용적인 만큼 중요한 지식을 그 사다리 아래로 이동시키십시오.

프롬프트는 판단을 설명해야 합니다.

하네스는 불변 조건을 강제해야 합니다.

12. 최종 답변뿐만 아니라 실행 과정도 관찰하라

깔끔한 최종 아티팩트는 끔찍한 프로세스를 숨길 수 있습니다.

에이전트가 다음과 같은 행동을 했을 수 있습니다:

• 잘못된 데이터에 접근
• 실패한 명령어 무시
• 외부 동작을 두 번 재시도
• 예상 예산의 10배 소비
• 잘못된 이유로 올바른 답변에 도달

실행을 재구성할 수 있는 추적이 필요합니다.

109:14  계약 생성됨
209:15  컨텍스트 소스 로드됨: architecture.md
309:17  파일 편집됨: checkout.ts
409:18  집중 테스트 실패: 중복 쿠폰
509:21  구현 수정됨
609:22  집중 테스트 통과
709:24  통합 테스트 통과
809:25  외부 배포 차단됨: 승인 필요

유용한 추적은 다음을 기록합니다:

• 상태 전환
• 컨텍스트 소스
• 도구 입력 및 출력
• 환경 변경
• 검증 결과
• 재시도 이유
• 승인 결정
• 비용 및 지연 시간

목표는 감시가 아닙니다.

목표는 국소적 수리입니다.

18단계에서 실행이 실패하면, 전체 작업을 재생하는 대신 신뢰할 수 있는 체크포인트에서 다시 시작할 수 있어야 합니다.

13. 모든 실행에는 변경 영수증이 필요하다

긴 에이전트 기록은 검토하기 어렵습니다.

실행이 끝나면 하네스는 작은 변경 영수증을 컴파일해야 합니다.

1목표
2체크아웃 시 중복 쿠폰 적용 문제 수정
3
4변경됨
5- 체크아웃 검증 로직
6- 집중 회귀 테스트
7
8검증됨
9- 린트 통과
10- 단위 테스트 통과
11- 체크아웃 통합 테스트 통과
12
13검증되지 않음
14- 프로덕션 결제 제공자
15
16결정
17- 기존 쿠폰 우선순위 순서 유지
18
19위험
20- 레거시 모바일 클라이언트를 로컬에서 사용할 수 없었음
21
22승인 필요
23- 스테이징에 배포

영수증은 모델이 말한 내용의 요약이 아닙니다.

시스템이 증명할 수 있는 것의 요약입니다.

이것은 인간에게 간결한 검토 표면을 제공하고 다음 에이전트 세션에 신뢰할 수 있는 시작점을 제공합니다.

최고의 인계는 "여기 대화가 있습니다"가 아닙니다.

"여기 상태, 증거, 그리고 해결되지 않은 위험이 있습니다"입니다.

14. 모든 실패는 하네스를 업그레이드해야 한다

가장 약한 팀은 실패한 출력물을 수정합니다.

가장 강한 팀은 그것을 가능하게 한 시스템도 수정합니다.

실패 후에 물어보십시오:

1작업 계약이 모호했는가?
2중요한 컨텍스트가 보이지 않았는가?
3잘못된 도구가 노출되었는가?
4사전 조건이 누락되었는가?
5결과를 검증할 수 없었는가?
6정책이 프롬프트 안에 남아 있었는가?
7복구가 너무 광범위했는가?
8추적이 불충분했는가?

그런 다음 교훈을 재사용 가능한 개선 사항으로 전환하십시오.

1실패
2  -> 진단
3      -> 새로운 센서, 규칙, 지도, 테스트 또는 도구 계약
4          -> 향후 실행이 자동으로 개선됨

이것이 하네스 플라이휠입니다.

실패가 뒤에 인프라를 남기기 때문에 시스템은 더욱 신뢰할 수 있게 됩니다.

수정된 답변은 한 번의 실행에 도움이 됩니다.

수정된 하네스는 모든 미래 실행에 도움이 됩니다.

15. 하네스도 쇠퇴한다

더 많은 하네스가 항상 더 나은 것은 아닙니다.

모델이 개선됩니다. 도구가 개선됩니다. 작업이 변합니다. 오래된 안전장치는 불필요한 마찰이 될 수 있습니다.

어제의 모델을 위해 만들어진 해결 방법이 오늘의 모델이 더 나은 전략을 사용하는 것을 막을 수 있습니다.

이것이 하네스 쇠퇴를 만듭니다:

1오래된 모델의 한계
2  -> 하네스 해결 방법
3      -> 모델 개선
4          -> 해결 방법이 남아 있음
5              -> 시스템이 느려지거나 능력이 떨어짐

하네스 구성 요소를 프로덕션 코드처럼 취급하십시오.

여전히 효용을 제공하는지 측정하십시오.

모든 라우터, 평가자, 메모리 계층, 재시도 규칙에 대해 물어보십시오:

• 이것은 어떤 실패를 방지하는가?
• 그 실패가 얼마나 자주 발생하는가?
• 이것이 얼마나 많은 지연 시간과 복잡성을 추가하는가?
• 동일한 결과를 이제 더 간단하게 얻을 수 있는가?
• 이것을 제거하면 어떻게 되는가?

최고의 하네스는 가장 큰 것이 아닙니다.

의도와 증거 사이의 격차를 안정적으로 좁히는 가장 작은 시스템입니다.

삭제하기 위해 구축하십시오.

16. 최소 실행 가능 하네스

시작하기 위해 오케스트레이션 플랫폼이 필요하지는 않습니다.

하네스를 계층별로 구축하십시오.

레벨 1: 제한된 작업

• 목표
• 범위
• 제약 조건
• 승인 검사

레벨 2: 읽기 쉬운 환경

• 프로젝트 지도
• 명령어
• 로컬 지침
• 알려진 종속성

레벨 3: 통제된 행동

• 타입화된 도구
• 인수 검증
• 경로 및 권한 경계
• 구조화된 결과

레벨 4: 지속적인 실행

• 명시적 실행 상태
• 체크포인트
• 결정
• 교훈

레벨 5: 증거

• 결정론적 검사
• 적대적 검증
• 변경 영수증

레벨 6: 복구 및 학습

• 실패 분류
• 제한된 재시도
• 에스컬레이션
• 반복되는 실패로부터의 하네스 업데이트

실제로 발생한 실패를 제거하는 가장 작은 계층을 구축하십시오.

단일 프롬프트가 가끔 명확화를 필요로 한다고 해서 멀티 에이전트 아키텍처로 시작하지 마십시오.

복잡성은 관찰된 실패에 의해 얻어져야 합니다.

17. 재사용 가능한 하네스 명세

에이전트에게 의미 있는 자율성을 부여하기 전에 다음을 정의하십시오:

1에이전트 하네스 명세
2
31. 계약
4   목표:
5   범위:
6   제약 조건:
7   승인 증거:
8
92. 컨텍스트
10   항상 로드되는 지도:
11   검색 소스:
12   로컬 지침:
13   신선도 규칙:
14
153. 도구
16   허용된 도구:
17   사전 조건:
18   부작용:
19   성공 증거:
20   타임아웃 및 재시도 정책:
21
224. 상태
23   사실:
24   결정:
25   진행 상황:
26   교훈:
27   체크포인트 형식:
28
295. 정책
30   자동 동작:
31   승인 필요 동작:
32   금지된 동작:
33   예산 한도:
34
356. 검증
36   결정론적 검사:
37   적대적 검사:
38   승인 규칙:
39
407. 복구
41   실패 클래스:
42   재시도 한도:
43   에스컬레이션 조건:
44   안전한 롤백:
45
468. 관찰 가능성
47   추적 이벤트:
48   메트릭:
49   최종 변경 영수증:

이러한 필드가 정의되지 않았다면, 에이전트는 자율적인 것이 아닙니다.

즉흥적으로 행동하는 것입니다.

18. 올바른 수준에서 시스템을 측정하라

토큰 수는 최종 메트릭이 아닙니다.

시도된 작업의 수도 마찬가지입니다.

유용한 단위는 수락된 작업입니다.

실용적인 메트릭은 다음과 같습니다:

1수락된 출력
2------------------------------
3인간 검토 시간 + 실행 비용

또한 다음을 추적하십시오:

• 첫 번째 통과 수락률
• 도구 실패 후 복구율
• 반복 실패율
• 작업당 인간 개입 횟수
• 뒷받침되지 않는 완료 주장
• 요청부터 검증된 결과까지의 시간
• 구성 요소별 하네스 오버헤드

이것은 일반적인 착각을 방지합니다:

에이전트는 매우 생산적으로 보이면서도 값비싼 검토 작업을 만들어낼 수 있습니다.

목표는 더 많은 에이전트 활동이 아닙니다.

인간의 주의력 단위당 더 신뢰할 수 있는 결과입니다.

19. 무거운 하네스가 필요하지 않은 경우

모든 모델 호출에 운영 체제가 필요한 것은 아닙니다.

다음과 같은 경우 간단한 프롬프트를 사용하십시오:

• 작업이 짧은 경우
• 출력을 검사하기 쉬운 경우
• 실패 비용이 저렴한 경우
• 외부 부작용이 없는 경우
• 사용자가 루프에 남아 있는 경우

다음과 같은 경우 하네스를 추가하십시오:

• 작업이 여러 도구 또는 세션에 걸쳐 있는 경우
• 환경이 변경될 수 있는 경우
• 행동에 실제 결과가 있는 경우
• 완료를 수동으로 판단하기 어려운 경우
• 동일한 실패가 반복적으로 나타나는 경우
• 인간 검토가 병목 현상이 되는 경우

하네스의 목적은 데모를 정교하게 보이게 하는 것이 아닙니다.

실제 작업을 신뢰할 수 있게 만드는 것입니다.

진정한 전환

첫 번째 세대의 AI 제품은 프롬프트를 중심으로 구축되었습니다.

다음 세대는 환경을 중심으로 구축되고 있습니다.

더 이상 질문은 다음과 같지 않습니다:

모델 답변을 어떻게 더 좋게 만들까?

다음과 같습니다:

좋은 행동은 쉽고, 위험한 행동은 통제되며, 실패는 가시적이고, 완료는 증명 가능한 시스템을 어떻게 구축할까?

이것이 프롬프트 엔지니어링에서 하네스 엔지니어링으로의 전환입니다.

모델은 지능을 제공합니다.

하네스는 구조를 제공합니다.

함께 신뢰할 수 있는 실행을 만들어냅니다.

에이전트가 계속해서 무너진다면, 프롬프트에 형용사를 더 추가하는 것을 중단하십시오.

성공하는 데 필요한 환경을 구축하십시오.

여기까지 읽으셨다면

이 가이드를 북마크에 추가하세요.

X에서 @LunarResearcher 팔로우하기

제 Substack 구독하기

모든 에이전트 실패를 더 긴 프롬프트로 해결하려고 하는 사람에게 이 글을 보내주세요.