에이전트 시스템은 먼저 컨텍스트 예산과 센서를 강화합니다.

Martin Fowler의 기사 Fragments: 7월 13일을 보면 가장 먼저 떠오르는 단어는 모델 점수가 아니라 Harness Engineering입니다. 수련회에서 일부 사람들은 이미 토론을 맥락과 센서에 넣었습니다. 이 문제는 새로운 엔지니어링 분야와 매우 유사합니다. 에이전트는 먼저 입력을 강화한 다음 작업 확장에 대해 이야기해야 합니다.

컨텍스트 창이 클수록 제약 조건은 짧아집니다.

기사에는 매우 간단한 세부 정보가 있습니다. 누군가가 agents.md를 200줄 이내로 제어했습니다. 이 숫자는 결벽증처럼 보이지만 실제로는 프로젝트를 위한 예산입니다. 컨텍스트 창이 실제로 점점 커지고 있지만 창이 커진다고 해서 더 많은 콘텐츠를 담을 수 있다는 의미일 뿐, 파악해야 할 부분을 모델이 더 확고하게 파악한다는 의미는 아닙니다. 모델은 일반적으로 컨텍스트의 작은 부분에만 초점을 맞추고 나머지 콘텐츠가 있더라도 계속 실행될 수 있습니다.

이는 긴 문서에서 가장 흔히 발생하는 문제입니다. 규칙이 많을수록 정말 중요한 제약 조건이 노이즈로 인해 모호해지기 쉽습니다. 설명이 길수록 경계를 배경으로, 배경을 경계로 쓰기가 더 쉽습니다. 파일을 짧게 유지하는 것은 작성 시간을 절약하는 것이 아니라 제약 조건을 표시하고, 읽고, 실행할 수 있도록 강제하는 것입니다. 에이전트가 직면한 것은 자재더미가 아니라 제한된 운영 계약이다.

센서는 사용 가능한 소량의 신호로 압축되어야 합니다.

또 다른 변화는 논의가 컴퓨팅 센서로 옮겨가기 시작했다는 것입니다. 여기의 센서는 단순히 포인트를 묻거나 모델에 로그를 다시 공급하는 것이 아니라 런타임 상태를 소수의 안정적인 신호로 압축합니다. 센서가 원래 출력 재생이 되면 입력이 다시 확장됩니다. 진정으로 가치 있는 접근 방식은 먼저 장면을 여러 가지 명확한 상태로 나눈 다음 어떤 세부 사항을 사람에게 제공하고 어떤 세부 사항을 도구에 제공해야 하는지 결정하는 것입니다.

기사에서는 Python에서 Rust와 같이 더 제어 가능한 언어로 전환하는 것이 이러한 맥락에서만 의미가 있다고 언급했습니다. 초점은 언어 선호도가 아니라 제어에 있습니다. 센서에 필요한 것은 "실행"이 아니라 명확한 경계, 명확한 예외 의미 체계 및 명확한 리소스 소비입니다. 신호가 불안정한 한 모델이 아무리 강하더라도 지터 입력을 기준으로만 판단할 수 있습니다.

하네스는 액션 체인을 먼저 닫습니다.

논의가 여기까지 진행되면 하네스는 쉘이라기보다는 마우스피스에 가까워집니다. 컨텍스트에 무엇이 들어가고 무엇이 남아 있는지를 결정하는 역할을 담당합니다. 모델이 신뢰할 수 있는 상태와 도구로 재확인해야 하는 상태는 무엇입니까? 컨텍스트 예산, 센서 설계, 권한 경계 및 대체 경로가 모두 마침내 이 계층에 제공됩니다.

에이전트 시스템에서 가장 쉽게 과소평가되는 비용도 이 수준에 속합니다. 모델 교체는 빠르지만 하네스는 액션 체인, 시그널 체인, 실패 체인에 묶여 있기 때문에 훨씬 느립니다. 이 계층이 강화되지 않고 모델 기능이 발전하는 한 시스템은 혼란을 더 빠르게 증폭시킬 뿐입니다.

순수한 읽기 요청, 일회성 분석 스크립트, 외부 작업이 없는 경량 에이전트, 모델 기능은 여전히 ​​주역입니다. 개인 데이터, 장기 상태 및 실제 동작을 연결하기 시작하자마자 가장 먼저 강화해야 할 것은 더 이상 모델 매개변수가 아니라 입력 경계와 신호 ​​경계입니다. 에이전트가 실제로 시스템과 유사한 순간은 종종 이 두 계층이 먼저 자리잡을 때입니다.