Белешки од терен

Агентски плаќања под човечка политика

Агентските плаќања се плаќања што ги иницира софтвер, а не човек на каса. AI агент држи акредитиви, одлучува дека треба да се направи купување и сам ги префрла парите — плаќа фактура, обновува претплата, резервира чартер — без човек да го притисне последното копче. Одлучувачки е иницијаторот. Човек што кликнува „купи“ е обично картично плаќање со чатбот пред него; агентското плаќање е софтвер што одлучува, одобрува и порамнува во моментот кога парите навистина се движат. Сè тешко во оваа категорија произлегува од таа една особина: тоа што троши не е човек и не се заморува, не станува сомнително и не се вознемирува како човек пред да префрли пари на непознат.

Затоа интересното прашање никогаш не беше дали агентите ќе трошат пари — веќе можат. Прашањето е кој ги поставува правилата под кои трошат и дали тие правила ги спроведува платформата или само ги ветува агентот.

Начинот на неуспех е очигледен, и во тоа е поентата

Дадете му на агентот жив платежен акредитив без таван и сте изградиле инцидент со измама што сè уште не се случил. Начинот на кој тоа тргнува наопаку не е егзотичен. Prompt injection скриен на веб-страница му кажува на агентот да плати на напаѓач. Неисправен опис на алатка го насочува легитимното купување кон погрешен примач. Јамка за повторување обидува иста наплата илјада пати бидејќи сигналот за успех никогаш не се вратил. Ништо од тоа не бара умен противник — тоа се обични грешки на автономен софтвер, освен што резултатот се пари што ја напуштаат вашата сметка.

Примамливото решение е агентот да биде попретпазлив: подобар системски prompt, построга инструкција, модел што појако размислува за трошењето. Тоа ја става контролата на најнепоуздано место во системот — во расудувањето на самиот агент, токму она што може да се наговори. Буџет што агентот може да го надмудри не е буџет. Контролата мора да живее таму каде агентот не може да допре, а тоа значи надвор од агентот.

Политиката е производот, не prompt-от

Моделот на ограничување е политика што платформата ја спроведува пред да се движат парите, а не откако агентот одлучил. Секој агент добива лимит по трансакција и дневен лимит — €150.00 по плаќање, €500.00 дневно во нашата демо-политика — со месечен таван од €6,000.00 над тоа. Тоа се цврсти ѕидови што ги проверува платформата, а не ветувања што ги држи агентот. Кога демо-ботот за патувања се обиде да закупи чартер за €640.00, плаќањето беше одбиено на место: над лимитот, пред да мръдне и цент. Агент што се однесува совршено секој ден сепак не може да надмине што дозволува месецот.

Буџетот кажува колку; листата на дозволени кажува каде. Агентите плаќаат само на трговци што сте ги именувале однапред. Демо Ops Agent знае точно четири, а обид од €180.00 кај продавач што не е на листата беше одбиен како not-listed. Заедно двете цртаат кутија: толку пари, само на овие примачи. Во кутијата агентот работи со полна брзина и никогаш не мора да праша; кутијата е она што го поседува човекот.

Прашањето не е дали AI агентот ќе троши пари. Туку кој ги напишал правилата под кои троши — и одговорот секогаш треба да биде човек, однапред, писмено.
— Protocore · Инженерство на Agents

Човек над линијата

Некои одлуки се преголеми за да се препуштат на кутија. Затоа политиката носи праг: утврден износ над кој човек мора да одобри пред плаќањето да помине. Во демото линијата е на €100.00. Кога Ops Agent ја означи фактурата #088 од Nord Logistics — €120.00, удобно во рамките на дневниот буџет од €500.00, но над линијата за одобрување — не плати. Застана, го стави предлогот пред човек и почека. Одговор од една линија го одобри; плаќањето се порамни со референца 9F21-0716 и влезе во ревизорската трага во 09:41. Под линијата агентот се движи сам; над неа, прво одговара човек.

Одобрувањето не е штикла што исчезнува. Бележи кој одобрил, на кој уред, во кое време, со прикачен потпис — одобрено во апликација, клуч на телефон, 09:41:12. Кога некој подоцна ќе праша зошто се случило плаќањето, одговорот е именувано лице и временски печат, а не вдигање раменици.

Kill-switch и дневник што не може тивко да се менува

Дури и во добри ѕидови, агентите грешат, а политиките излегуваат погрешни. Две контроли се грижат за тоа. Првата е kill-switch: еден допир го паузира агентот и веднаш ги запира сите плаќања што би можел да ги иницира. Клучевите остануваат валидни за ништо друго да не се скрши — агентот едноставно не може да троши додека човек не го вклучи повторно, а неговите предлози на чекање се замрзнуваат на место наместо да исчезнат. Во демо-флотата ботот за патувања стои паузиран со €0.00 потрошено, а неговата редица е недопрена.

Второто е дневник за ревизија што само се дополнува (append-only). Секоја одлука е забележана: што се обидел да направи агентот, која проверка на политиката поминала или паднала, кој што одобрил, сè до ротацијата на клучевите. Еден запис реконструира цело плаќање — одлуката DEC-4471 го прикажува барањето, секоја проверка на политиката со нејзиниот резултат (allowlist: поминато, лимит: поминато, праг: ескалација), човечкиот потпис и порамнетиот износ со неговиот канал и референца. Секој запис носи свој хеш, хеш на претходниот запис и своја позиција во синџирот — #4,471 во демото — па со менување на кое било поле се прекинуваат сите записи по него. Дневникот се извезува како JSON, заедно со хешот: ваш е да го предадете на ревизор, не наш да го чуваме.

Порамнувањето нека биде досадно; новитетот оставете го за авторизацијата

Постои искушение плаќањата преку агенти да се направат нови до дното — нова шина, нов инструмент, нов начин на движење на парите. Одолејте. Вистински новиот дел е авторизацијата: како агентот докажува дека смее да плаќа, според чија политика и со какво одобрување. Штом плаќањето ќе ја помине таа порта, треба да се порамни преку канали што со години се досадни. Во демото, одобрен предлог од €120.00 станува обичен SEPA кредитен трансфер — порамнет преку SEPA Instant неколку минути по одобрувањето — неразличлив надолу по синџирот од плаќање што го направил човек. Банката не знае, ниту ја интересира, дека го иницирал агент.

Оваа поделба е намерна. Досадните канали се предвидливи, отповикливи таму каде што шемата го дозволува тоа, и ги разбира секој трезор и ревизор со кого ќе работите. Кога новитетот е во политиката, а плаќањето на веќе проверен канал, ризичниот и брзоменлив дел е оној што целосно го контролирате, а делот што допира туѓи банки е оној што никој не мора одново да го учи. Агентите трошат од истото јадро врз кое работи остатокот од семејството на плаќања — опишано на /products/pay — а не од паралелен свет направен за роботи.

Протоколите сè уште не се смирени — градете според тоа

Како агентот треба да го претстави својот идентитет и мандат пред трговецот е отворено прашање. Неколку предлози се натпреваруваат во тоа како агентот докажува кој е, што смее да купува и како трговецот го проверува тоа пред да ги прифати парите. Ниеден не победил, а да се обложи сè на еден од нив денес би било предвреме. Одбранбениот пристап е протоколот за авторизација да се третира како заменлив, а сè зад него да остане стабилно: политиката, моделот на ревизија и каналот за порамнување не се менуваат кога се менува форматот на фронтот.

Во пракса тоа значи мала, досадна површина за интеграција. Агентите се поврзуваат преку MCP на mcp.protocore.io/agents; секој фрејмворк што го зборува протоколот може да држи паричник. Интерфејсот е намерно тесен — предложи плаќање, добиј одлука — бидејќи интересната логика живее на платформата, а не во промптот. Кога индустријата ќе се договори како агентите се докажуваат пред трговците, се менува фронтот, а ѕидовите зад него остануваат точно таму каде што биле.

Каде се вклопува ова

Плаќањата преку агенти не се обложување дека автономниот софтвер треба да троши без ограничување. Напротив: тоа е обложување дека софтверот ќе троши, па ограничувањата подобро да бидат вистински, надворешни и читливи. Буџетите и allowlist-ите ја цртаат рамката, прагот ги упатува големите одлуки кај човек, kill-switch го запира сè, а дневникот што само се дополнува значи дека секое плаќање може подоцна да се реконструира. Страницата на производот на /products/agents ја поминува целата јамка на демо податоците користени тука — создај агент, постави му политика, гледај како плаќање ескалира и се порамнува — а /products/pay е јадрото врз кое работат тие плаќања. Автономијата е вистинска; вистинска е и каишот, а го држи човек.

Имате систем за градење?

Кажете ни го проблемот. Ќе се вратиме со архитектура и план.